So far I have been testing .Net Memory Profiler to see if we would like to acquire it, and up until now it has been very helpful. However, there is one problem that is beginning to defeat the purpose of Memory Profiler, in that it blocks my internal exception trapping.
Basically, we have had a rather pesky memory leak at one of our clients facilities. The window's service side of our application apparently dies frequently with "out of memory" exceptions. But we can't specifically find the path that is creating this problem. Now, I've been testing this and trying to determine what is still in memory that is not being released correctly, and up until now had been unsuccessful in reproducing the error on my development system. During that process I had been using the manual sos.dll method via Visual Studio to try and find the leak but to no avail, so I decided to try .Net Memory Profiler. After some trial and error I figured out how to get the memory maps correctly with the application and yet was still unable to cause the same error. Once we acquired our client's actual database, I tried again, and voila:
.Net Memory Profiler -> Profile Exe -> Run the Process 2 to 3 times, and boom, I get a message from Profiler: "Profiling Session stopped due to an out-of-memory condition. Do you want to save profiler session".
I thought great! Now I know that I can reproduce the error. So I put in an Exception trapper in my code, that would pop up a dialog with all the exception information (most importantly the Stack Trace) and tried again. But Profiler is blocking or pre-empting my code. I cannot have this. I don't care if an out of memory exception is triggered my code is supreme above all and I need to stop Profiler from interrupting my own exception handling process. If it is constantly killing the process and stopping execution of the code when the OOM exception is thrown, I can't figure out what is causing the exception. If I can't verify that the out of memory is occurring along similar path lines in the code then I can't resolve the issue and the .Net Memory Profiler is useless.
How do I stop this behavior. I just want the profiler to watch the heap, and take snapshots, I'll do the thinking, not the computer. I have to attach to the process and get the information without Profiler doing anything to the original process.
Jaeden "Sifo Dyas" al'Raec Ruiner
The message you see, "Profiling Session stopped due to an out-of-memory condition", occurs when the profiler itself has failed to allocate memory within the profiled process. In this case, there is no .NET OutOfMemoryException that can be caught. When the process runs very low on memory, either the profiled program can cause the memory error, or the profiler. In both cases, the call stack of the actual allocation that caused the error will often not tell you what's causing the memory problem. For instance, a small 12-byte allocation case cause the out-of-memory exception, even though the main memory usage is caused by some other unrelated memory allocations, perhaps in a different thread.
Below are some scenarios that can cause out of memory error.
1. Memory leak, that causes "slow" increase in memory usage. This scenario can be normally be detected long before you run out of memory, by collecting and comparing snapshots in the profiler.
2. "Real" out of memory. Your application actually needs more memory than available. The only way to solve this is to add more memory, or try to optimize the memory usage. The memory usage can be optimized by collecting snapshots in the profiler and analysing the memory usage. Again, it should hopefully be possible to detect the excessive memory usage when using a smaller dataset (to prevent OOM while profiling).
3. Out of address space. If you allocate large blocks of memory in a 32-bit process, you can get an out of memory error, even if there are a lots of physical and virtual memory available. This can normally be detected by catching the OOM exception in the debugger. If you are allocating a large block when the error occurs, try to investigate whether it is possible to divide the memory blocks into smaller pieces.
4. Too large allocation by "mistake". If the size of the memory allocation is based on data from an external source, e.g. a file, then corrupted data can cause a large allocation. This should also be easy to detect in the debugger.
Since you get the message "Profiling Session stopped due to an out-of-memory condition", it appears like your are experiencing scenario 1 or 2. If you are not able to detect this before the OOM error occurs, then one option is to use Debugging Tools attach. When attaching using Debugging Tools, no profiler code is running within the profiled process, and there's no memory overhead. However, collecting snapshots will be much slower, and the information will not be as detailed. When you detect the OOM error, e.g. by breaking into the debugger, you can collect a snapshot. This snapshot will contain information about all managed instances, and you will see the call stack of the offending allocation in the debugger.
In a future release of the profiler, we will detect OutOfMemoryExceptions in the profiled process and present them in the profiler. This will at least provide useful information in scenario 3 and 4.
SciTech Software AB
These were great features to add. Are there any plans on the implementation of some features for the first two scenarios?Andreas Suurkuusk wrote: In a future release of the profiler, we will detect OutOfMemoryExceptions in the profiled process and present them in the profiler. This will at least provide useful information in scenario 3 and 4.
Users browsing this forum: Google [Bot] and 18 guests