Re: Undebuggable StackOverflowException, possibly related to hotfi
From: joc (j.coulmance_at_free.fr)
Date: 11/16/04
- Next message: b.bardugo: "Calling user control from VBScript (managed and un-managed)"
- Previous message: Nadav: "RE: Resizing an existing PE section"
- Messages sorted by: [ date ] [ thread ]
Date: 16 Nov 2004 02:34:18 -0800
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
"Niall" <asdf@me.com> wrote in message news:<#Qifc68vEHA.2120@TK2MSFTNGP14.phx.gbl>...
> 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...
> > You should use sos.dll
> > Do a search on msdn for sos.
> > !EEStack
> > will show all the stacks known to clr
> > ~*e !clrstack
> > Will execute !clrstack for all threads
> >
> > Look for the thread with the longest output ;)
> >
> > "Niall" wrote:
> >
> > > 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
> > >
> > > "Dmitriy Zaslavskiy" <dimkaz25@yahoo.com> wrote in message
> > > news:uBipknJvEHA.3976@TK2MSFTNGP09.phx.gbl...
> > > > There is a difference whether the stack overflow happends in the JITed
> code
> > > > or in unmanaged code.
> > > > for example
> > > > void f()
> > > > {
> > > > f();
> > > > }
> > > > Willl generate perfectly catch(able) exception and your app will be
> able
> to
> > > > recover.
> > > > However
> > > > void f()
> > > > {
> > > > Guid g = Guid.NewGuid; // Calls a lot of unmanaged code
> > > > f();
> > > > }
> > > > Will most likely (it really depends on exact stack depth) will
> generate an
> > > > exception that cannot be caught
> > > > and will take your application down right away. It is the next "best
> thing"
> > > > to ExecutionEngineException!
> > > > That is FailFast will take the process down.
> > > > The last thing your app does is to consult the registry to check if
> debugger
> > > > is registered and call the debugger.
> > > >
> > > > So my suspicion is that you are having the second type.
> > > > So instead attaching VS (especially in managed mode! this mode needs
> debug
> > > > thread in process to talk to)
> > > > I would attach Windbg (with SOS) and get stack trace.
> > > > I can almost guarantee it will work ;)
> > > >
> > > >
> > > > "Niall" <asdf@me.com> wrote in message
> > > > news:em0yaTIvEHA.2520@TK2MSFTNGP15.phx.gbl...
> > > > > 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
> > > > >
> > > > > "Justin Rogers" <Justin@games4dotnet.com> wrote in message
> > > > > news:O7Elds9uEHA.3456@TK2MSFTNGP14.phx.gbl...
> > > > >> Can you continue running the application? If the UI thread is still
> responsive
> > > > >> then your
> > > > >> problem is located on one of your background threads. If you don't
> have
> > > > >> background
> > > > >> threads, then that would be awesome to let us know, because then
> you
> have
> some
> > > > >> extremely strange problems.
> > > > >>
> > > > >> To note, there were some changes to GDI+, and not really all that
> much
> of
> > > > >> anything else.
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Justin Rogers
> > > > >> DigiTec Web Consultants, LLC.
> > > > >> Blog: http://weblogs.asp.net/justin_rogers
> > > > >>
> > > > >> "Niall" <asdf@me.com> wrote in message
> > > > >> news:u1MW7s8uEHA.944@TK2MSFTNGP11.phx.gbl...
> > > > >> >I am experiencing a StackOverflowException suddenly in an
> application
> that
> > > > >> > hasn't changed and had not previously experienced a StackOverflow
> in
> > > > >> > the
> > > > >> > months it's been in use.
> > > > >> >
> > > > >> > The JIT debugging window appears on the machine and I choose to
> debug
> with a
> > > > >> > new instance of Visual Studio. However, the debugger is unable to
> > > > >> > attach
> to
> > > > >> > the process, and I cannot obtain a call stack. Under normal
> operation,
> the
> > > > >> > debugger can attach to the process without problems. I have
> created a
> test
> > > > >> > project that causes StackOverflowExceptions and it is debuggable,
> I
> can
> even
> > > > >> > see the call stack to see what's responsible for the overflow. So
> I
> guess
> > > > >> > the debugger not being able to attach may be due to some kind of
> stack
> > > > >> > corruption.
> > > > >> >
> > > > >> > I racked my brains to work out what could cause this problem. The
> > > > >> > application is small and doesn't use any recursion, so I am at a
> loss
> for
> > > > >> > where to start.
> > > > >> >
> > > > >> > The error occurs on a number of machines, so it's not a hardware
> > > > >> > problem
> as
> > > > >> > far as I can see. I checked the event log and noticed that some
> > > > >> > hotfixes
> > > > >> > from windowsupdate had been automatically installed to all
> machines
> running
> > > > >> > the application, around the time that the problem began
> occurring.
> The
> > > > >> > hotfixes that were installed were:
> > > > >> >
> > > > >> > - Cumulative Security Update for Internet Explorer 6 Service Pack
> 1
> > > > >> > (KB834707)
> > > > >> > - Security Update for Windows XP (KB873376)
> > > > >> > - Security Update for Windows XP (KB841356)
> > > > >> > - Security Update for Windows XP (KB840987)
> > > > >> > - Security Update for Windows XP (KB841533)
> > > > >> > - Security Update for Windows XP (KB824151)
> > > > >> >
> > > > >> > I am in the process of removing the hotfixes to see if the
> problem
> > > > >> > continues.
> > > > >> >
> > > > >> > One odd thing about the exception is that when the JIT debugging
> window
> is
> > > > >> > open, asking me to select a debugger, the main GUI thread of the
> application
> > > > >> > remains responsive. I can scroll text boxes, highlight text, and
> the
> > > > >> > GUI
> > > > >> > redraws without problems. I would have expected the whole process
> to
> be
> > > > >> > frozen.
> > > > >> >
> > > > >> > Does anyone have any advice on approaches I can take to find out
> more
> about
> > > > >> > what's happening? Without a call stack, it's very difficult to
> > > > >> > determine
> > > > >> > what's at fault.
> > > > >> >
> > > > >> > Thanks,
> > > > >> >
> > > > >> > Niall
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
- Next message: b.bardugo: "Calling user control from VBScript (managed and un-managed)"
- Previous message: Nadav: "RE: Resizing an existing PE section"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
