Re: gdb: Symbolized Crash Report: One line spans multiple functions?
Re: gdb: Symbolized Crash Report: One line spans multiple functions?
- Subject: Re: gdb: Symbolized Crash Report: One line spans multiple functions?
- From: Jerry Krinock <email@hidden>
- Date: Tue, 29 Dec 2009 14:53:31 -0800
Well, all this wailing and gnashing of teeth finally got me close enough to find the crash I was looking for, so I'm done with this problem.
Besides my conclusion that gdb's 'info line' may sometimes erroneously point to the line containing the closing curly bracket of a function when the crash actually occurred earlier (although this may be due to bad information from the compiler), I also believe that Crash Reporter omitted two functions in my call stack. Besides the missing function call between rows 0 and 1 that I noted yesterday, I believe that the top function (#0) in the call stack was not the one in which the crash occurred, but that the crash actually occurred in another method, which that top method called. No, it was not an autorelease crash. Seven statements before the end of the method, I had sent a message to an uninitialized object. When I reproduced the crash while running in Xcode, the call stack pointed this out perfectly. Has anyone ever seen this Crash Reporter miss the boat like this?
Regarding my question yesterday about how to find the target and selector by examining the disass code and reading the register mov statements above a dyld_stub_objc_msgSend, I now believe that this is quite difficult. A method appears to be given in "The Mac® Hacker’s Handbook" by Charlie Miller and Dino A. Dai Zovi, pages 145-149. I hope I never need to use it. Maybe I won't, if I get some time to try out that new compiler and start using the static analyzer :)
Thanks for the help!
Jerry
_______________________________________________
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