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.