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: Jason Molenda <email@hidden>
- Date: Mon, 28 Dec 2009 19:57:47 -0800
On Dec 28, 2009, at 7:41 PM, Jerry Krinock wrote:
> 0xeb12d <-[ExtoreG(Loginner) logInWithInfo:]+884>: add $0x4c,%esp
> 0xeb130 <-[ExtoreG(Loginner) logInWithInfo:]+887>: pop ëx
> 0xeb131 <-[ExtoreG(Loginner) logInWithInfo:]+888>: pop %esi
> 0xeb132 <-[ExtoreG(Loginner) logInWithInfo:]+889>: pop íi
> 0xeb133 <-[ExtoreG(Loginner) logInWithInfo:]+890>: leave
> 0xeb134 <-[ExtoreG(Loginner) logInWithInfo:]+891>: ret
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. 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 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 "*".)
> 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.
> 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.
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.
J _______________________________________________
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