[re] Java executables can abort trying to access a null pointer in a leaf function

Thu Feb 2 18:39:00 GMT 2006

David Daney writes:
 > Andrew Haley wrote:
 > > David Daney writes:
 > > > Andrew Haley wrote:
 > > > > tsuraan writes:
 > > > > > > Someone will need the assembly and/or object file for a small test case
 > > > > > > to examine the DWARF frame data.
 > > > > > 
 > > > > > I can send a tarball of the entire directory, if desired. It's 14 KB
 > > > > > without the core dump and 1.2MB with it. I don't know what filesize
 > > > > > starts to anger people on this list, so I'll just send the smaller
 > > > > > tarball for now. If the core is desired, I can send that too.
 > > > > 
 > > > > This looks OK to me: we are generating te null pointer check. 
 > > > > 
 > > > > Until we actually see the faulting instruction in gdb we're not going
 > > > > to get anywhere. Just load your program into gdb, run it, and tel us
 > > > > when it hits the SEGV.
 > > > > 
 > > > 
 > > > Uh, I don't think there was a fault. There is an explicit call to 
 > > > _Jv_ThrowNullPointerException, then we abort because the unwinder fails.
 > > 
 > > That's what I'm trying to prove.
 > > 
 > > I think there is probably bad debuginfo for
 > > NullPointer.foo(NullPointer). Looking at the backtrace in gdb will
 > > give us a good idea.
 > > 
 > The stacktrace that tsuraan supplied shows that the abort happens at the 
 > abort() at the bottom of _Jv_Throw, exactly were it happened to me a 
 > while ago when I had bad .eh_frame data.
Well, let's have a look:
000000ec <NullPointer.foo(NullPointer)>:
 ec: 55 push %ebp
 ed: 89 e5 mov %esp,%ebp
 ef: 83 ec 08 sub 0ドルx8,%esp
 f2: a1 00 00 00 00 mov 0x0,%eax
 f7: 83 c0 05 add 0ドルx5,%eax
 fa: a3 00 00 00 00 mov %eax,0x0
 ff: 8b 45 0c mov 0xc(%ebp),%eax
 102: 89 45 fc mov %eax,0xfffffffc(%ebp)
 105: 8b 45 fc mov 0xfffffffc(%ebp),%eax
 108: 85 c0 test %eax,%eax
 10a: 75 05 jne 111 <NullPointer.foo(NullPointer)+0x25>
 10c: e8 fc ff ff ff call 10d <NullPointer.foo(NullPointer)+0x21>
 111: 8b 45 fc mov 0xfffffffc(%ebp),%eax
 114: 89 c2 mov %eax,%edx
 116: 8b 42 04 mov 0x4(%edx),%eax
 119: 83 c0 04 add 0ドルx4,%eax
 11c: 89 42 04 mov %eax,0x4(%edx)
 11f: c9 leave 
 120: c3 ret 
 121: 90 nop 
000000a0 0000001c 000000a4 FDE cie=00000000 pc=000000ec..00000121
 LOC CFA r5 ra 
000000ec r4+4 u c-4 
000000ed r4+8 c-8 c-4 
000000ef r5+8 c-8 c-4 
So, after the instruction at location 0xef the CFA (Caller Frame
Address) is at r5 (AKA %ebp) + 8, the previous r5 (AKA %ebp) is saved
at CFA - 8, and RA (Return Address) is at CFA - 4.
That looks right to me. I'm guessing that the unwinder never found
this info.
Andrew.