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: Mon, 28 Dec 2009 22:01:47 -0800
On 2009 Dec 28, at 19:57, Jason Molenda wrote:
> This is a function epilogue, there's nothing crashing here. The instruction pointer points to the following instruction when the processor is executing an instruction on x86. So the crashing instruction is the one before 0xeb12d.
Yes.
> Because the x86 ISA uses variable length instructions, you can't just subtract some value to see the previous instruction, you need to disassemble the entire function and look for the prev insn.
I don't see any insn, but let's move on.
> I wasn't paying very close attention in my previous email; I did not provide the correct syntax for getting the disassembly of a function given an address. The correct syntax is
>
> (gdb) disass 0xeb12d
>
> (no "*".. 'info line' needs the "*".)
Got it.
>
>> 2 com.myCompany.Bkmxwork 0x000f112d 0x6000 + 962861
>
> Given that this function is on the stack, I'm guessing the preceding instruction is a CALL - and given the source you quote, it's probably a call to objc_msgSend.
Yes, you are correct. It moves a bunch of stuff (target, selector and arguments, I presume) to registers and then sends a message...
0xeb111 <-[ExtoreG(Loginner) logInWithInfo:]+856>: mov 0x10(ëp),êx
0xeb114 <-[ExtoreG(Loginner) logInWithInfo:]+859>: mov êx,0x8(%esp)
0xeb118 <-[ExtoreG(Loginner) logInWithInfo:]+863>: mov 0x40a69(ëx),êx
0xeb11e <-[ExtoreG(Loginner) logInWithInfo:]+869>: mov êx,0x4(%esp)
0xeb122 <-[ExtoreG(Loginner) logInWithInfo:]+873>: mov 0x8(ëp),íx
0xeb125 <-[ExtoreG(Loginner) logInWithInfo:]+876>: mov íx,(%esp)
0xeb128 <-[ExtoreG(Loginner) logInWithInfo:]+879>: call 0xec0bc <dyld_stub_objc_msgSend>
0xeb12d <-[ExtoreG(Loginner) logInWithInfo:]+884>: add $0x4c,%esp
>> So the lesson is maybe to not trust gdb's 'info line' when it gives you a line number that is the ending curly bracket of a function. Interpret as "somewhere near the end of that function".
>
> I'd say it's more a matter of what information the compiler provides to the debugger - the debugger is faithfully reporting what is going on here.
I'll append to my "lesson" that, "Of course, the fault may be that gdb got inaccurate info from the compiler".
> One simple experiment would be to do "info line *0xeb12c". This is unlikely to be a valid instruction address but it will be an address within the bounds of the source line that caused the problem. That will point the finger at either the logOutThenInWithInfo: or runModalSheetAlert: call lines.
(gdb) info line *0xeb12c
Line 95 of "/Users/jk/Documents/Programming/Projects/Project1/ExtoreG+Loginner.m" starts at address 0xeb111 <-[ExtoreG(Loginner) logInWithInfo:]+856> and ends at 0xeb12d <-[ExtoreG(Loginner) logInWithInfo:]+884>.
Indeed, Line 95 is the message to -logOutThenInWithInfo.
So, I would expect the next item up in the crash report's call stack to be within -logOutThenInWithInfo.
1 com.myCompany.Bkmxwork 0x000f0b90 0x6000 + 961424
With the slide, that's 0xeab90:
(gdb) p/x 0x000f0b90-0x6000
$1 = 0xeab90
(gdb) info line *$1
Line 135 of "/Users/jk/Documents/Programming/Projects/Project1/ExtoreG+Loginner.m" starts at address 0xeab6d <-[ExtoreG(Loginner) doLoginWithInfo:]+189> and ends at 0xeab92 <-[ExtoreG(Loginner) doLoginWithInfo:]+226>.
So now we've got another inconsistency since doLoginWithInfo: is not the expected logOutThenInWithInfo:. If I disass I find that 0xeab90 is after another message send, and it is in doLoginWithInfo. So, I'm going to go with doLoginWithInfo, "see no evil", and assert that, for some reason, Crash Reporter *omitted a line* in the call stack. (I've pasted in logOutThenInWithInfo: at the end of this message.)
But of course I'm more interested in the crash. I disassed the whole doLoginWithInfo: method and see that there are fourteen message sends in the source code and fourteen dyld_stub_objc_msgSend calls in the assembly code. Woohoo. All I have to do is figure out which one in the source code corresponds to this one...
0xeab6d <-[ExtoreG(Loginner) doLoginWithInfo:]+189>: lea -0x1c(ëp),êx
0xeab70 <-[ExtoreG(Loginner) doLoginWithInfo:]+192>: mov êx,0xc(%esp)
0xeab74 <-[ExtoreG(Loginner) doLoginWithInfo:]+196>: mov íi,0x8(%esp)
0xeab78 <-[ExtoreG(Loginner) doLoginWithInfo:]+200>: mov 0x40d6e(ëx),êx
0xeab7e <-[ExtoreG(Loginner) doLoginWithInfo:]+206>: mov êx,0x4(%esp)
0xeab82 <-[ExtoreG(Loginner) doLoginWithInfo:]+210>: mov 0x40f9e(ëx),êx
0xeab88 <-[ExtoreG(Loginner) doLoginWithInfo:]+216>: mov êx,(%esp)
0xeab8b <-[ExtoreG(Loginner) doLoginWithInfo:]+219>: call 0xec0bc <dyld_stub_objc_msgSend>
<<<<<<< CRASH >>>>>>>>
0xeab90 <-[ExtoreG(Loginner) doLoginWithInfo:]+224>: mov êx,íi
Now I suspect that one of those constants in one of those mov can be decoded to a target class, and another one can be decoded to a selector name. I've been reading docs for an hour but haven't found the incantation yet. I hope the answer is not 'info symbol' because what I get from that is way off. What is it?
Thanks!
Jerry
- (void)logOutThenInWithInfo:(NSMutableDictionary*)info {
SSYProgressView* progressView = [[self bkmslf] progressView] ;
[progressView setIndeterminate:YES
withLocalizedVerb:[NSString localize:@"loggingOut"]] ;
[SSYSynchronousHttp SSYSynchronousHttpUrl:[self logoutUrl]
httpMethod:@"GET"
bodyString:nil
username:nil
password:nil
timeout:30.0
userAgent:constUserAgent
response_p:NULL
receiveData_p:NULL
error_p:nil] ;
// will block here until logged out
[progressView clearAll] ;
[self doLoginWithInfo:info] ;
}
_______________________________________________
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