Locked. This question is not currently accepting new answers or interactions. Learn more.
Let's say there is a program on my Windows XP system leaking.exe which leaks token handles at a rate that will eventually render the system unusable. It's black box to me, can't get support or examine/debug/modify the source code.
Also let's say restarting the system and restarting leaking.exe are undesirable fixes. This will work but I am trying to find a way to avoid it.
All I know at this point is using process explorer I can see it is building a massive list of token handles, for the default login user.
I don't know much about token resources. What would be a typical cause for a token leak? Seems to me something like starting a thread that never ends, but there is no thread leaking going on.
How would token handles relate to other resources like files or other running processes? If there were a way to mitigate this problem by manipulating something else related to the leak that would be nice.
Sorry for the vague details but it is a very vague problem. Thanks for any suggestions!
Related
Currently our staging IIS puts 100% load on the CPU.
(I wasn't allowed to post with an image so I'll link it: http://i40.tinypic.com/1444qww.png)
I currently have been unable to find the cause of this behavior since the stack of the thread that causes the high load does not contain any application specific references. If anyone sees more in this screenshot then I or had a similar experience I'm glad to hear it.
Info:
Windows Server 2k8R2
If any more information is required I shall try to provide.
Thanks.
We found that one of the business layer classes was loading a 50k+ table into a dictionary in memory in its initialization. This caused the long wait as well as the high load. Changing this swiftly fixed our problem.
I don't see any way to start/stop profiling in Instruments from code, which kinda kills its usefulness for me in a large number of situations.. Am I missing something? Does anyone know of a way to do this?
The fallback approach is to grab performance data on my own, without Instruments. Has anyone tried to do this before? By "performance data" I mean counts of events like cache misses, fills, missed branches, etc.
Thanks!
Update:
I looked into operating the performance monitor hw directly from code, but, unsurprisingly, it appears to be a no-go. USEREN, the "user enable register" controls access to perfmon registers but is not enabled. It might be possible to run privileged or enable user access with a jailbroken phone, but that's a lot of work for some basic profiling.. ugh.
This is a philosophical question. My program send message that need more memory. I release all memory I can to it continue working correct. But, the program tell that need more memory again, and I have no one to release. What I do now?
This almost happens when I am using the camera with the ZBar library, so I don't have control with the ZBar (I can't release it's memory, only mine). And this really need a lot of memory to work. Because this, I don't know what I do.
The program didn't crash, but can run unstable.
Without more details to your problem, your answers are going to be vague :)
The obvious answer is to use less memory.
If depends on what you're using the memory for but you could consider putting it into a file on disk and only reading in the data that you need?
You should also check for leaks - you might be using memory without realising it.
If you post more information about your exact problem, we could probably help more.
I'm quite impressed by what Lift 2.0 brings to the table with Actors and StatefulSnippets, etc, but I'm a little worried about the memory overhead of these things. My question is twofold:
How does Lift determine when to garbage collect state objects?
What does the memory footprint of a page request look like?
If a web crawler dances across the footprint of the site, are they going to be opening up enough state objects to drown out a modest VPS (512M)? The question is very obviously application dependent, but I'm curious if anyone has any real world figures they can throw out at me.
Lift stores state information in a session, so once the session is destroyed the state associated with that session goes away.
Within the session, Lift tracks each page that state is allocated for (e.g., mapping between an ajax button in the browser and a function on the server) and have a heart-beat from the browser. Functions for pages that have not seen the heartbeat in 10 minutes are unreferenced so the JVM can garbage collection them. All of this is tunable, so you can change heart-beat frequency, function lifespan, etc., but in practice the defaults work quite well.
In terms of session explosion, yeah... that's a minor issue. Popular sites (including http://demo.liftweb.net/ ) experience it. The example code (see http://github.com/lift/lift/tree/master/examples/example/ ) detects sessions that were created by a single request and then abandoned and expires those early. I'm running demo.liftweb.net with 256MB of heap size (that'd fit in a 512MB VPS) and occasionally, the session count rises over 1,000, but that's quickly tamped down for search engine traffic.
I think the question about memory footprint was once answered somewhere on the mailing list, but I can’t find it at the moment.
Garbage collection is done after some idle time. There is, however, an example on the wiki which uses some better heuristics to kill off sessions spawned by web crawlers.
Of course, for your own project it makes sense to check memory consumption with something like VisualVM while spawning a couple of sessions yourself.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
I'm having a lot of issues with trying to perform some core data operations in a threaded NSOperation.
Currently, I have created a managed object context in my app delegate that is purely used on my threaded NSOperations. I setup a NSOperationQueue with a max concurrency of 1 so each action is performed serially. For each operation (that gets data from the internet and creates new managed objects), I pass it the context to use. Once the new objects have been created, I save and reset the context for the next operation to use. However, I'm intermittently getting malloc errors while doing this, and I've spent days trying to figure it out, and it would appear to have something to do with how it is threaded.
The errors I'm getting can be seen in this related stack overflow question.
The malloc error is occurring when I'm simply setting a managed object's property to an NSNumber object. It is also the first time I'm setting that property so it is nothing that I am over releasing myself! I can't figure it out at all, and I can't reproduce the error using GuardMalloc, it just doesn't occur! It's as if the error is happening somewhere else that is being triggered, but I have no idea where!
All I can deduce then is that the error is somehow connected with how I've set up the whole thing. I have tried running the operation myself instead of adding it to the NSOperationQueue and it appears to work fine (although it hangs the main thread!).
I also need the context to inform other contexts in my app when saves have been made, so I observe it's NSManagedObjectContextDidSaveNotification notification. However, since saves are being performed in the NSOperation (other thread), will there be problems with this as notifications are only dispatched on the thread it's running in?
Have you read the Multi-Threading with Core Data section of the Core Data Programming Guide?
Resurrecting an old question, but this might help someone - I ran into similar problems with the same setup described here (dedicated context for each NSOperation, max concurrency of one), and I found out that it was due to the fact that I was creating the NSOperation-dedicated context on the main thread, and then I tried to use it in an NSOperation thread. Once I moved context creation into the NSOperation's main function, the problems were gone.
Right, I've managed to get it all working now, much to my relief. After days of messing around, I decided to rewrite all the code to do with the threading and core data and I'm no longer getting the malloc errors. It is a rather complex setup so there must have been something pretty obscure in there!