No stack trace for System.OutOfMemory

[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?

 

[Chris LaJoie]

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

 

[Mike Schilling]

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.

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.

Nor do I.