tags:

views:

37

answers:

1

When I'm writing a program for the iPhone, what the apple environment does when something goes wrong (from "unrecognized selector" to anything else), the app crashes and at the console, I have this meaningless stack debug spew that looks like this:

2009-12-19 11:57:37.843 ModelsProg[394:207] Stack: (
    30884955,
    2431960329,
    31266875,
    30836342,
    30688962,
    10115,
    2721311,
    2759178,
    2747272,
    2729683,
    2756789,
    38981329,
    30669696,
    30665800,
    2723433,
    2760707,
    9948,
    9802
)

Honestly I can't think of a more useless way to try and help a developer track the bug. It doesn't even tell you what line the problem is from, unless [394:207] is some cryptic indication of where the bug happened.

How can I:

  • Have the mac development environment tell me line number error and file occurred
  • Suppress the meaningless stack chatter or change it to __actual function names__ as output, like Python's crashing bug output looks.
+1  A: 

You are running a binary without symbols (a Release binary, probably) or the crash is happening in a spot where the crashtrace mechanism can't get to the symbols (like an uncaught exception). Those #s are the addresses that would normally be looked up to produce a symbol.

Generally, for a stack spew like that, there is an uncaught exception log message on the line immediately before the spew. That is generally going to give you just about all the information you need.

However, if you do need to symbolicate the stack trace, there are a couple of ways to do so.

If you are in gdb, you can use info symbol 30884955 (obviously, substitute various numbers) to get a hold of more information about the symbol at that address in the stack trace. info line *30884955 is likely to produce even more useful results.

The key, though, is that you need the symbol files somewhere accessible. From Xcode, they should just be there (unless you have broken the symbol generation configuration of your app). Otherwise, you would need to load them using the symbol-file command.

If you want to automate this or do symbolication outside of gdb, use the atos command.

bbum
"crashtrace mechanism can't get to symbols" - hmm! This ALWAYS happens whenever I crash an objective-c program from XCode.The way you suggested to track down the error source seems awfully manual. What are "symbol files"?
bobobobo
Symbol files are the bits that the compiler writes to correlate executable to source. See documentation. You still haven't indicated what the exception is; that you are under Debug indicates that you have the ability to set a breakpoint on the exception raise. See documentation again (or google).
bbum