On Tue, 17 Jul 2012, Donovan Watteau wrote:
> On Mon, 16 Jul 2012, Philip Guenther wrote:
>> On Mon, 16 Jul 2012, Donovan Watteau wrote:
>> > >Description:
>> > All threaded programs end up segfaulting on my B&W G3 (Rev 1).
>> > This makes most ports unusable, since a lot of ports use threads
>> > (or a library that links to them), i.e: they almost always crash
>> > at start-up.
>> >
>> > This looks specific to the G3 processor, as I'm surprised it
>> > hasn't been reported yet.
>> >
>> > Please see the output of base gdb [1] and gdb-7.4.1 from
>> > ports [2]. They come from the core-dump of the following
>> > "thread_eight" program.
>> > >How-To-Repeat:
>> > Here's how I tried to get some information from gdb:
>> > * Compile a threaded program (here, thread_eight.c [3])
>> > * Start compiling a port. If the machine is completely idle, the
>> > segfault is much harder to catch.
>> > * Repeatedly launch the binary. It should eventually crash and
>> > produce a core-dump.
>> > * Then, launch gdb (or egdb) on it to get some information.
>> ...
>> > #0 0x9129ef30 in pthread_self () at tcb.h:60
>> > 60 __asm__ ("lwzx %0, %%r2, %1" : "=r" (val) : "r"
>> > (offset));
>>
>> Can you show the output of "info regs" for that thread?
>
> Here you go:
>
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "powerpc-unknown-openbsd5.2"...
> Core was generated by `thread_eight'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/libpthread.so.16.0...done.
> Loaded symbols for /usr/lib/libpthread.so.16.0
> Reading symbols from /usr/lib/libc.so.65.0...done.
> Loaded symbols for /usr/lib/libc.so.65.0
> Reading symbols from /usr/libexec/ld.so...done.
> Loaded symbols for /usr/libexec/ld.so
> #0 0x9129ef30 in pthread_self () at tcb.h:60
> 60 __asm__ ("lwzx %0, %%r2, %1" : "=r" (val) : "r" (offset));
> (gdb) info regs
> Undefined info command: "regs". Try "help info".
> (gdb) info reg
> r0 0x4 4
> r1 0x8e8a0ea0 2391412384
> r2 0x9032 36914
> r3 0x1860de8 25562600
> r4 0x1810ba4 25234340
> r5 0x8e8a0f94 2391412628
> r6 0x86ca4100 2261401856
> r7 0x800 2048
> r8 0x2b 43
> r9 0x912e22f8 2435719928
> r10 0x891e5fd2 2300469202
> r11 0x9129e3f0 2435441648
> r12 0x24000024 603979812
> r13 0x0 0
> r14 0x0 0
> r15 0x0 0
> r16 0x0 0
> r17 0x8f040000 2399404032
> r18 0x30634 198196
> r19 0xffff6060 4294926432
> r20 0x1 1
> r21 0xffff6094 4294926484
> r22 0x0 0
> r23 0x15 21
> r24 0xffff609c 4294926492
> r25 0xffff6004 4294926340
> r26 0x5e 94
> r27 0x912c2064 2435588196
> r28 0x1860de8 25562600
> r29 0x1810ba4 25234340
> r30 0x912d2168 2435653992
> r31 0x8e8a0f94 2391412628
> pc 0x9129ef30 2435444528
> ps 0xd032 53298
> cr 0x24000024 603979812
> lr 0x912d2168 2435653992
> ctr 0x9129e3f0 2435441648
> xer 0x24000024 603979812
> fpscr 0x0 0
> vscr 0x0 0
> vrsave 0x0 0
> (gdb)
I'm afraid to report that the exact same problem still exists on a
8 November snapshot, which I reinstalled from scratch.
