Re: Bug#753791: simgrid: FTBFS on hurd-i386
tony mancill, le Wed 09 Jul 2014 22:26:19 -0700, a écrit :
> (gdb) bt
> #0 0x012ab278 in gnu.classpath.tools.gjdoc.Main.start(java.lang.String[])int (
> this=@80c8eb0, args=@8099f98)
> at ../../../../../src/libjava/classpath/tools/gnu/classpath/tools/gjdoc/Main.java:1050
This is:
0x012c3270 <+864>: call 0x1183980 <_Jv_LookupInterfaceMethodIdx@plt>
0x012c3275 <+869>: mov %ebp,(%esp)
=> 0x012c3278 <+872>: call *%eax
(gdb) info registers
eax 0xe9707512 -378505966
That's indeed not a valid pointer, _Jv_LookupInterfaceMethodIdx@plt
returned a completely bogus value.
(gdb) disassemble
Dump of assembler code for function _Jv_LookupInterfaceMethodIdx(jclass klass, jclass iface, int method_idx):
0x0203d730 <+0>: mov 0x4(%esp),%eax
klass (in $eax) is 0x361fdc0
0x0203d734 <+4>: mov 0x6c(%eax),%edx
cldt = klass->idt (in $edx) is 0x80af960
0x0203d737 <+7>: mov 0x8(%esp),%eax
iface (in $eax) is 0x3698100
0x0203d73b <+11>: movswl (%edx),%ecx
cldt->iindex (in $ecx) is 7
0x0203d73e <+14>: mov 0x6c(%eax),%eax
iface->ioffsets (in $eax) is 0x815f280
0x0203d741 <+17>: movswl (%eax,%ecx,2),%eax
iface->ioffsets[cldt->iindex] is 2
0x0203d745 <+21>: add 0xc(%esp),%eax
method_idx is 13, thus idx is eventually 15
0x0203d749 <+25>: mov 0x4(%edx,%eax,4),%eax
and there, cldt->itable[15] brings the bogus 0xe9707512
The content of that table is indeed:
(gdb) p/x ((unsigned long*) 0x80af964)[0]
$95 = 0x3615900
(gdb) p/x ((unsigned long*) 0x80af964)[1]
$96 = 0x362eb80
(gdb) p/x ((unsigned long*) 0x80af964)[2]
$97 = 0x241d970
(gdb) p/x ((unsigned long*) 0x80af964)[3]
$98 = 0x23f9060
(gdb) p/x ((unsigned long*) 0x80af964)[4]
$99 = 0x241db10
(gdb) p/x ((unsigned long*) 0x80af964)[5]
$100 = 0x240ae10
(gdb) p/x ((unsigned long*) 0x80af964)[6]
$101 = 0x362f1c0
(gdb) p/x ((unsigned long*) 0x80af964)[7]
$102 = 0x23fad60
(gdb) p/x ((unsigned long*) 0x80af964)[8]
$103 = 0x23faf30
(gdb) p/x ((unsigned long*) 0x80af964)[9]
$104 = 0x23fafc0
(gdb) p/x ((unsigned long*) 0x80af964)[10]
$105 = 0x0
(gdb) p/x ((unsigned long*) 0x80af964)[11]
$106 = 0x3620a48
(gdb) p/x ((unsigned long*) 0x80af964)[12]
$107 = 0x80af990
(gdb) p/x ((unsigned long*) 0x80af964)[13]
$108 = 0x14
(gdb) p/x ((unsigned long*) 0x80af964)[14]
$109 = 0xe
(gdb) p/x ((unsigned long*) 0x80af964)[15]
$110 = 0xe9707512
Most values are proper pointers, except 0 of course, and 0x14, 0xe,
0xe9707512.
I don't know how this dispatch table gets filled, and whether 15 is a
sane value for it, but at least something odd is happening there.
0x0203d74d <+29>: ret
Samuel
Reply to: