Note: There was a bad value `' for the field `Class'.
	It was set to the default value of `sw-bug'.

>Number:         30749
>Category:       port-amiga
>Synopsis:       pthread_create ends in abort if stacksize limit over 4088k
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-amiga-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 14 21:52:00 +0000 2005
>Originator:     S.P.Zeidler
>Release:        NetBSD 2.0.2_STABLE
>Organization:
dis-
>Environment:
System: NetBSD serpens.de 2.0.2_STABLE NetBSD 2.0.2_STABLE (SERPENS) #0: Fri Jul 8 08:34:14 CEST 2005 spz@aquila:/home/netbsd/obj.amiga/sys/arch/amiga/compile/SERPENS amiga
Architecture: m68k
Machine: amiga
>Description:

--- snip ---
#include <pthread.h>
#include <stddef.h>

void *thread_routine(void *data) {
    return data;
}

int main() {
    pthread_t thd;
    pthread_mutexattr_t mattr;
    pthread_once_t once_init = PTHREAD_ONCE_INIT;
    int data = 1;
    pthread_mutexattr_init(&mattr);
    return pthread_create(&thd, NULL, thread_routine, &data);
}
--- snap ---
compiled by:
cc -o whatthehell -O2 -DNETBSD whatthehell.c -lm -lcrypt -lresolv
-lpthread

will, when run and stacksize limit is 4089k or higher, yield on my Amiga:
8% ./whatthehell && echo ok
Abort (core dumped)

(and it'll take around two minutes and brake all processes on the machine
to a standstill when it does that)

gdb says to that:
#0  0x0808a746 in kill () from /usr/lib/libc.so.12
#1  0x080f183c in abort () from /usr/lib/libc.so.12
#2  0x0805d8de in pthread__sa_start () from /usr/lib/libpthread.so.0
#3  0x08060816 in pthread_init () from /usr/lib/libpthread.so.0
#4  0x08060bcc in pthread_create () from /usr/lib/libpthread.so.0
#5  0x00002910 in main ()
#6  0x00002650 in __start ()

If my stacksize limit is 4088k or less it just finishes 'immediately'
and I get an 'ok' printed from the echo as fast as I can discern.

The problem doesn't occur in i386 or sparc64, but may be occurring in
other m68k architectures (testers?). It's been with us at least since
2.0RC1, probably longer.

>How-To-Repeat:
	see above
>Fix:
	workaround: lower stacksize limit :-P