On 10 Nov 2012, Donovan Watteau wrote:
> 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.
FWIW, I'm still having the same issue with a 21 December snapshot.
