Re: What does this stack mean?
Re: What does this stack mean?
- Subject: Re: What does this stack mean?
- From: Jonny Taylor <email@hidden>
- Date: Wed, 6 Dec 2006 23:08:02 +0000
- Authenticated-sender:
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.
Thanks
Jonny
_______________________________________________
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