dotnet clr: Undebuggable StackOverflowException, possibly related to hotfixes from windowsupdate -- dotnet clr

Re: Undebuggable StackOverflowException, possibly related to hotfixes from windowsupdate

Niall
10/28/2004 10:25:43 AM

The application runs a few threads. I was under the impression that by the
time the window comes up asking for a debugger selection, the whole process
would have bombed from the StackOverflow. Not so?

The application in question launches our commercial application and performs
some automated testing on it. When it's finished testing, it kills the
tested application's process. When we added logging to the application with
the StackOverflow, it appeared that the last message on the black box was
frequently that it was killing the process, though it's not always the case.

Another odd thing is that when the StackOverflowException occurs, both
applications - the tester and the tested are undebuggable. I have also seen
the case where the tested application has the StackOverflow.

So my best guess is that something in the way the tested application shuts
down is causing this problem.

Do you have more information or links to information about the GDI+ changes?

Thanks for your help,

Niall

[quoted text, click to view]

Re: Undebuggable StackOverflowException, possibly related to hotfixes from windowsupdate

Niall
10/28/2004 10:46:06 AM

Unfortunately, I can't reproduce it reliably, it just happens often enough
to make life a pain :P

I added a whole lot of logging to the application to see where it got up to
before it went off the air. I would have thought that if there was some
situation in my code where recursion would occur (none has been deliberately
coded), it would be reflected in the logging. Perhaps this means that the
overflow is happening in some .Net code we call, which might be revealed by
a stack walk as you say. I'll try your suggestion, I hope I can reproduce
the error!

Thanks,

Niall

[quoted text, click to view]

Re: Undebuggable StackOverflowException, possibly related to hotfixes from windowsupdate

Niall
10/28/2004 2:18:45 PM

Dmitriy,

Thanks for your post. I have tried attaching Windbg to the process once it
has already had the StackOverflowException. When I did, I wasn't able to see
the call stack for the threads that remained in the process, the call stack
window was blank. I have almost no experience with Windbg, so it would be
fair to say I don't really know what I'm doing :P

Should I be using the sos.dll.ClrStack method to see the call stack? In my
previous attempt, I just used the call stack window, which gave me messages
like "Stack unwind information not available". I tried using ClrStack with a
test project and was able to see the managed call stack, so this seems to be
the go.

Thanks for the advice, I'll try Windbg again next time I see the exception
occur.

Niall

[quoted text, click to view]

Re: Undebuggable StackOverflowException, possibly related to hotfi

Niall
11/1/2004 3:50:59 PM

We've found the cause of the stack overflow, though it hasn't answered all
of our questions about what is going on.

The overflow is caused by an exception being raised when trying to call
..ToString() on an Exception. When we try to report an exception back to the
developers, we get another exception and end up in the unhandled exception
handler, which then tries to report it, and we end up in... the unhandled
exception handler.

So the overflow we can fix. Using Windbg, we can see that we are getting
SEHExceptions .ToString() when the Exception goes off to get callstack
information. We haven't been able to get more information on this
exception...

Thanks for your help, I've learned a bit about how to use Windbg and will be
mindful of that potential pitfall with unhandled exception handlers in the
future!

Niall

"Dmitriy Zaslavskiy" <Dmitriy Zaslavskiy@discussions.microsoft.com> wrote in
message news:79DC154D-F7E4-4002-80F0-6A0FE6C6B9F9@microsoft.com...
[quoted text, click to view]

Re: Undebuggable StackOverflowException, possibly related to hotfi

j.coulmance NO[at]SPAM free.fr
11/16/2004 2:34:18 AM

Hi Niall,

I am experiencing an issue similar to yours. My application is a mix
of managed and unmanaged code hosted by IIS. The stack overflow occurs
when Exception.ToString() calls Exception.StackTrace. Unfortunately,
the code base is quite huge and the problem resists any attempt at
isolating a small portion reproducing the exception.
Strangely, if you call "new StackTrace()" before the first exception
is raised, the stack overflow disappears. Even more strangely, calling
"new StackTrace" only once in the first execution of the involved
method will remove stack overflows in subsequent calls.
Moreover the issue seems influenced by the size of the data in the
stack: in the code below, if you replace "char dummy[2000]" by "char
dummy[1000]" the stack overflow disappears (though dummy is not used,
it is here only to reserve some space on the stack).

My original code looks like this:

void Test::Execute()
{
char buffer[2000];
try
{
// code raising the first exception comes here
}
catch(Exception *e)
{
e->StackTrace; // stack overflow
}
}

The hack I've found is presented below:

bool stackOverflowCircumventionDone = false;
void Test::Execute()
{
// hack to circumvent a mysterious stack overflow when calling
Exception::StackTrace (which is called by Exception::ToString() in
diagnostic messages)
// it seems like calling "new StackTrace()" at least once prevents
stack mess
if (!stackOverflowCircumventionDone)
{
new StackTrace();
stackOverflowCircumventionDone = true;
}

char buffer[2000];
try
{
// code raising the first exception comes here
}
catch(Exception *e)
{
e->StackTrace; // no more stack overflow
}
}

Did you find a solution to your problem ? Is it the same as mine ?

Regards,

Jocelyn

[quoted text, click to view]

Re: Undebuggable StackOverflowException, possibly related to hotfi

Niall
11/17/2004 4:28:56 PM

Hi Jocelyn,

We haven't found the cause of our problem. We have been able to work around
it so that it doesn't really affect us any more, but the problem itself
still exists. I think it may be the case that the heap is corrupted by the
time the problem manifests. It's hard to tell. Occasionally, we also get
messages saying something along the lines of "failed to load resources",
which might be consistent with a corrupted heap.

In my original post, I listed some hotfixes that were installed on our
machines around the time that the problem started to manifest itself. Do you
have any of those installed also? How long have you been experiencing the
problem for?

I'll give your code a shot to see how it behaves for us.

Thanks,

Niall

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the dotnet clr group.