Lists

Open Menu Close Menu

Terms and Conditions
Lists hosted on this site
Email the Postmaster
Tips for posting to public mailing lists

Re: What does this stack mean?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What does this stack mean?

Subject: Re: What does this stack mean?
From: David A Rowland <email@hidden>
Date: Wed, 6 Dec 2006 15:45:27 -0800

At 11:08 PM +0000 12/6/06, Jonny Taylor wrote:

At 9:46 AM +0000 12/6/06, Jonny Taylor wrote:
Hi all,
I've been looking at a crash report for my app, and the top of the stack looks like this:
#0   0x00089d5c in _Unwind_Find_registered_FDE
#1   0x00089fc8 in _Unwind_Find_FDE
#2   0x00085c88 in uw_frame_state_for
#3   0x0008603c in uw_init_context_1
#4   0x00086400 in _Unwind_RaiseException
#5   0x00087f38 in __cxa_throw
#6   0x0002010c in _ZN6Record8SetValueElPKcll
(where line #6 is my code, which does indeed throw an exception). I know that it threw this particular exception (from the same line of code) a number of times previously, with no discernible ill effects, and then did this crash a bit later - though I suspect the call stack may have been different on the final time when it crashed. Does anyone know what this call stack means? From inspection of my code appearing higher up in the call stack I _would_ expect the exception to be caught successfully before it propagated out of my code. Is this just a symptom of a corrupted stack, or can I interpret it as something specific?
It smells like code that is not exception safe. The Wikipedia entry
http://en.wikipedia.org/wiki/Exception_handling
discusses it. I suggest you read that.
Thanks for the link that was a good reminder about the principles of exceptions.

This crash is likely a rogue pointer.
I appreciate that. Maybe I should have been more specific in my question. What I should have said is: I understand that the root cause of the problem is that I had a "rogue pointer" involved somewhere in the code executed prior to this crash. I would be interested to know more about what these unwind functions are doing, in the hope of getting a clue as to how to track down this bug in my code.

My guess would be that the crash is because I have got a scribbler somewhere which has corrupted the stack pointers that the gcc-generated code is relying on in order to unwind the stack to a "catch" block. However it would be really helpful if anyone familiar with these functions (or able to point me to some source code) was able to help me confirm if this is a reasonable interpretation or whether I am misunderstanding what this unwinding code does.

One mildly interesting thing is that this is _not_ an exception being rethrown from a catch block or anything: up to this point is has been mainline code which has been executed. This makes it slightly harder to know where to look for the problem, since it can't have been caused by a bug in a (maybe poorly-tested) "catch" block - as my reading of the stack is that no catch blocks have been executed by this point. It's possible that I'm wrong in that interpretation though, as I don't know the details of how gcc actually goes about unwinding the stack.

The reason I am interested in understanding this as closely as possible is that all I have to go on is an unreproducible scenario from a user that resulted in this crash log. Record::SetValue was asserting on one of the parameters it was passed, and this failed assertion led to the exception being thrown. From the full call stack I have a pretty good guess as to where the bad parameter came from, but I am concerned that I don't know why that should cause this crash. The code IS designed to conform to "commit or rollback semantics", in the words of the wikipedia article, and when I attempt to repro the bug the code does behave as designed in so far as it successfully recovered from the exception by returning everything to its initial state, and no crash occurs.

However evidently there is a bug in my code somewhere which leads to violation of this principle and thence to the crash... so if anyone could point me to an explanation of how the gcc exception-handling glue works I'd be really interested.

The exception "unwinding" code is in a library whose name escapes me at the moment. At each level of unwinding it does these things; 1. check whether the current point of execution is inside a "try" block 2. If not, call destructors for all locally defined objects 3. dump this frame and step up the calling chain to the previous frame, go to step 1. If there is no previous frame, kill the program. 4. If it is in a try block, examine the catch clauses for a match 5. If a match is found, execute its code and continue 6. If no match is found, go to step 3

I think that is right. The compiler creates links to the locally defined objects so the exception code can find them. The exception code is written with knowledge of how the stack frame is organized. _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden Follow-Ups: Re: What does this stack mean? From: Jonny Taylor <email@hidden> References: >What does this stack mean? (From: Jonny Taylor <email@hidden>) >Re: What does this stack mean? (From: David A Rowland <email@hidden>) >Re: What does this stack mean? (From: Jonny Taylor <email@hidden>) Prev by Date: Re: What does this stack mean? Next by Date: newbie question about Makefiles Previous by thread: Re: What does this stack mean? Next by thread: Re: What does this stack mean? Index(es): Date Thread