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

[Andrew Haley <aph at redhat dot com>]

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.

Andrew.