Le 30 juin 08 à 09:59, Joan Lluch (casa) a écrit : El 30/06/2008, a las 0:11, Chris Espinosa escribió: On Jun 29, 2008, at 12:53 PM, Jens Alfke <email@hidden> wrote:
On 29 Jun '08, at 12:20 PM, Joan Lluch (casa) wrote: By setting a Breakpoint at objc_exception_throw or [NSException raise] I am able to stop my program when (for example) an out of range exception is thrown. However the call stack trace on the debugger window or the 'bt' command only shows a single line. For example:
I've also had this happen occasionally with various breakpoints (not just objc_exception_throw); I'm not sure what causes it or how to prevent it.
Is this in a debug or a release build of your app? Optimized code can sometimes lead to confused backtraces, although it should never get this bad.
A common cause of a truncated backtrace on exception handling is if your function somehow corrupted the return stack, which may also have caused the exception in the first place. A buffer overrun or bad cast on a function local is a common cause of this.
Chris
Thanks to all for your replies. I actually have all sorts of problems related to the call stack with the debugger, for example the step over command usually does not work, and it performs a step into instead. This is annoying because it turns de debugger completely useless, without the ability to see the stack trace or to run the app step by step.
I am using XCode 3.0 and yes, I compile the app as debug with compiler optimisation turned off and debug symbols generation enabled. I start to get frustrated about it because I don't get it.
And just in case, which debug symbol format ? You should use dwarf, if this is not the case, it may be the cause of your problems.
|
