2009/6/18 Gavin Sherry <[email protected]> > 2009/6/18 Bojan Smojver <[email protected]> > >> On Thu, 2009-06-18 at 13:22 +0200, Gavin Sherry wrote: >> >> > Do, we're trying to store r0 (int 6144) at 4(r5) = 4 + 844(r2) above. >> > Seems like this should all work fine... remarkably trivial stuff. I've >> > even tried two different versions of GCC with the same result. :( >> >> So, if you stop and try to examine that particular address, does it >> crash too? >> > > (My message has been getting caught by your spam filter. Must be all the > references to registers and so on. Hopefully more meaningful text here will > make that stop). > > > This is quite weird. > > (gdb) print &proc_mutex_op_try > $4 = (struct sembuf *) 0x20001f00 > (gdb) set proc_mutex_op_try.sem_flg = 1111 > (gdb) print proc_mutex_op_try > $5 = {sem_num = 0, sem_op = 0, sem_flg = 1111} > (gdb) info registers > r0 0x1800 6144 > r1 0x2ff228b0 804399280 > r2 0x200018c8 536877256 > r3 0xffffffff -1 > r4 0x20001f48 536878920 > r5 0x1001e828 268560424 <----- > r6 0x20000ab0 536873648 > r7 0x1001e84c 268560460 > r8 0x1001e840 268560448 > r9 0x0 0 > r10 0x0 0 > r11 0x1000 4096 > r12 0x48244280 1210335872 > r13 0xdeadbeef -559038737 > r14 0x1 1 > r15 0x2ff22a04 804399620 > r16 0x2ff22a0c 804399628 > r17 0x0 0 > r18 0xdeadbeef -559038737 > r19 0xdeadbeef -559038737 > r20 0xdeadbeef -559038737 > r21 0xdeadbeef -559038737 > r22 0xdeadbeef -559038737 > r23 0xdeadbeef -559038737 > r24 0xdeadbeef -559038737 > r25 0xdeadbeef -559038737 > r26 0xdeadbeef -559038737 > r27 0xb 11 > r28 0x20000900 536873216 > r29 0x10000000 268435456 > r30 0x2ff22948 804399432 > r31 0x0 0 > pc 0x10005e74 268459636 > ps 0x2d0b2 184498 > cr 0x44244242 1143226946 > lr 0x100079b4 268466612 > ctr 0x0 0 > xer 0x8 8 > fpscr 0x0 0 > vscr 0x0 0 > vrsave 0x0 0 > (gdb) ni > > > Program received signal SIGSEGV, Segmentation fault. > apr_proc_mutex_unix_setup_lock () at locks/unix/proc_mutex.c:176 > 176 proc_mutex_op_try.sem_flg = SEM_UNDO | IPC_NOWAIT; > 1: x/i $pc 0x10005e74 <apr_proc_mutex_unix_setup_lock+44>: sth > r0,4(r5) > > So, when we try and put r0 in memory at r5 + 4, we're trying to overwrite > a part of memory where proc_mutex_op_try is not actually defined. > > I might try current GCC and see if that helps. Alternatively, I've seen > some other pre built APR binary releases for AIX. I'll disassemble the > relevant function and see what's going on there. > > Other than that, does anyone else on the list have access to AIX? Can the > problem be recreated? The hardware on the machine itself seems sound as I've > compiled several other large pieces of code which do not exhibit this kind > of peculiar behaviour. >
I reverted to an older compiler (gcc 4.0.0, shipped by IBM) and the tests pass. So, this seems to be a compiler bug for this platform. Thanks for your help. Gavin
