No stack trace for System.OutOfMemory

  • Thread starter Thread starter Mike Schilling
  • Start date Start date
M

Mike Schilling

Instances of SystemOutOfMemoryException do not contain a stack trace. Easy
test to verify this:

class OOM
{
public static void Main() {
try {
Object[, ] arr = new Object[100000000, 10000000];
} catch (Exception ex) {
dumpEx(ex);
}
}

private static void dumpEx(Exception ex) {
Console.WriteLine("Exception occurred");
Console.WriteLine(ex);
String s = ex.StackTrace;
if (s == null)
Console.WriteLine("Stack trace is null");
else
Console.WriteLine("StackTrace length is " + s.Length);
}
}

Output:

Exception occurred
System.OutOfMemoryException: Exception of type System.OutOfMemoryException
was thrown.
Stack trace is null

This makes debugging these exceptions tricky, to say the least. I wound up
having to track down where the exception was being generated with
WriteLines. I know that you can trap these is Visual Studio as well, but
this one was touchy (it turned out to be a synchronization problem) and the
performance degradation from running an ASP.NET program inside Visual Studio
made it stop happening. Two questions:

1. Are there any tricks that I'm missing for debugging these more
effectively?

2. Can we expect to see stack traces in some future release?
 
OutOfMemory exceptions sometimes occur because there's too much in the call
stack (i.e. if a function unconditionally recursively calls itself). In
that situation, the call stack IS the reason for the OutOfMemory exception,
and it wouldn't really make sense to have it available for examination.
Knowing which function caused the error is generally enough (I would think).
However, don't see any reason why a stack trace can't be supplied for the
error you're generating in the example. Sorry I don't have an answer for
you, just though I'd offer my insight.

Chris LaJoie
 
Chris LaJoie said:
OutOfMemory exceptions sometimes occur because there's too much in the call
stack (i.e. if a function unconditionally recursively calls itself). In
that situation, the call stack IS the reason for the OutOfMemory exception,
and it wouldn't really make sense to have it available for examination.
Click to expand...

Sure, and it's also possible that the heap is exhausted so there isn't room
to construct a stack trace.
Knowing which function caused the error is generally enough (I would think).
However, don't see any reason why a stack trace can't be supplied for the
error you're generating in the example.
Click to expand...

Nor do I.
 
Back
Top