From: Godmar Back (gback@cs.utah.edu)
Date: Fri Feb 05 1999 - 17:47:51 EST
Okay, I tracked it down to this, which may or may not ring a bell
for Alexandre.
java_lang_System_initProperties does this:
setProperty(p, "java.vendor.url", kaffe_vendor_url);
setProperty(p, "java.compiler", getEngine());
The call to getEngine is a call in a jumptable, like so:
call 0x401ee29c
(gdb) x/10i 0x401ee29c
0x401ee29c <_init+1580>: jmp *0x188(%ebx)
0x401ee2a2 <_init+1586>: pushl $0x2f8
0x401ee2a7 <_init+1591>: jmp 0x401edc9c <_init+44>
%ebx is the register holding the base address for the pic code,
computing at the entry to java_lang_System_initProperties.
Now look at this table: (I replaced __DTOR_END__ with _)
0x401f72c0 <_+4>: 0x0000d504 0x00000000 0x00000000 0x4018c2a0
0x401f72d0 <_+20>: 0x40034d58 0x40026320 0x08049284 0x4016dc90
0x401f72e0 <_+36>: 0x4018d7a0 0x40035b80 0x40033890 0x40034a38
0x401f72f0 <_+52>: 0x40167a70 0x401f3050 0x40033ec4 0x400328bc
0x401f7300 <_+68>: 0x400348d0 0x4018dcc0 0x401f3f58 0x40021744
0x401f7310 <_+84>: 0x40020b44 0x401f2cf0 0x401a7310 0x4003194c
0x401f7320 <_+100>: 0x401f3d80 0x400333bc 0x40031eb4 0x40031d08
0x401f7330 <_+116>: 0x40034a64 0x40034198 0x40033710 0x400279bc
0x401f7340 <_+132>: 0x400350f8 0x400318a0 0x401f2c54 0x401a6af0
0x401f7350 <_+148>: 0x401f4244 0x40069a30 0x40031e1c 0x40033494
0x401f7360 <_+164>: 0x40034ac8 0x40024374 0x4017fa10 0x400277dc
0x401f7370 <_+180>: 0x4018b7a0 0x40031fa0 0x4001a1bc 0x400329a4
0x401f7380 <_+196>: 0x401f34dc 0x4003162c 0x401f41b4 0x400350b8
0x401f7390 <_+212>: 0x400317b0 0x40034974 0x4001bc04 0x4018c7e0
0x401f73a0 <_+228>: 0x4001bd28 0x401f3cfc 0x4001af0c 0x40034d38
0x401f73b0 <_+244>: 0x400276f0 0x4018c6b0 0x401f4100 0x400353d0
0x401f73c0 <_+260>: 0x40031b58 0x4019e290 0x401f44e4 0x4001c320
0x401f73d0 <_+276>: 0x4003377c 0x4001bc48 0x4001ad2c 0x401f0948
0x401f73e0 <_+292>: 0x40160d40 0x4018bb20 0x40031f30 0x401a61d0
0x401f73f0 <_+308>: 0x4003489c 0x401b2d70 0x40027820 0x00004172
0x401f7400 <_+324>: 0x00004182 0x00004192 0x000041a2 0x000041b2
0x401f7410 <_+340>: 0x000041c2 0x000041d2 0x000041e2 0x000041f2
0x401f7420 <_+356>: 0x00004202 0x00004212 0x00004222 0x00004232
0x401f7430 <_+372>: 0x00004242 0x00004252 0x00004262 0x00004272
0x401f7440 <_+388>: 0x00004282 0x00004292 0x000042a2 0x000042b2
^^^^^^^^^^
0x401f7450 <_+404>: 0x000042c2 0x000042d2 0x000042e2 0x000042f2
0x401f7460 <_+420>: 0x00004302 0x00004312 0x00004322 0x00004332
0x401f7470 <_+436>: 0x00004342 0x00004352 0x00004362 0x00004372
0x401f7480 <_+452>: 0x00004382 0x00000000 0x40057ed0 0x40057f20
0x401f7490 <_+468>: 0x40057ec8 0x40057ecc 0x40057f18 0x40057f1c
0x401f74a0 <_+484>: 0x40057f24 0x40057ec4 0x40057f14 0x40057e30
0x401f74b0 <_+500>: 0x4004f77c 0x40057f28 0x40057e58 0x40057e60
The marked part is where we're jumping to and segfault.
Where could a pattern like this (numbers increasing by 16) come from?
Note that the surrounding addresses are fine: 0x40027820 points to
<getDataJarFile>, and 0x40057ed0 points to data symbols such <byteClass>
So, the question is: is this a bug in ld.so?
Is libtool at all involved in this? I don't believe so.
Do we trash the table maybe? But who would write a pattern like that?
And why does it only happen when SIGVTALRM is enabled *and* unblocks
the signals from with the handler? Is it because ld.so's routines are
not async-signal-safe?
Anyway, just thought I'd let you know in case this rings a bell.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:58 EDT