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

[David Daney]

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    $0x8,%esp
>   f2:   a1 00 00 00 00          mov    0x0,%eax
>   f7:   83 c0 05                add    $0x5,%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    $0x4,%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.