apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gavin Sherry <...@alcove.com.au>
Subject Re: Segfault in testlockperf test on AIX
Date Thu, 18 Jun 2009 20:30:10 GMT
2009/6/18 Gavin Sherry <swm@alcove.com.au>

> 2009/6/18 Bojan Smojver <bojan@rexursive.com>
>
>> 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

Mime
View raw message