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

Thu Feb 2 18:51:00 GMT 2006

Andrew Haley wrote:
> 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.
>Yeah, on linux/glibc it uses dl_iterate_pheader() (sp?) to find 
infromation about the loaded objects from there it can find the 
.eh_frame sections.
David Daney.