开发者

Better bail behavior in face of bug, Mac OS development

开发者 https://www.devze.com 2022-12-14 22:28 出处:网络
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 con

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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消