Bug#753791: simgrid: FTBFS on hurd-i386

[Samuel Thibault <sthibault@debian.org>]

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