The following reply was made to PR port-amiga/30749; it has been noted by GNATS.

From: "Michael L. Hitch" <mhitch@lightning.msu.montana.edu>
To: gnats-bugs@NetBSD.org
Cc: port-amiga-maintainer@NetBSD.org, <gnats-admin@NetBSD.org>,
	<netbsd-bugs@NetBSD.org>, "S.P.Zeidler" <spz@serpens.de>
Subject: Re: port-amiga/30749: pthread_create ends in abort if stacksize
 limit over 4088k
Date: Mon, 9 Oct 2006 15:14:32 -0600 (MDT)

 On Thu, 14 Jul 2005, S.P.Zeidler wrote:
 
 > 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)
 
   I'd guess that writing the coredump is probably what stops everything
 until it finishes.
 
 > 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.
 
   The problem is that pthread_sa_start() will allocate 16 stacks for 16
 upcall threads.  The amiga user address space is only 224M, of which 6M
 is available for text, 128M for data, and 32M for the process stack.
 The remaining space is where shared libraries and other mmap() regions
 are placed.  Attempting to mmap() 16 stacks of over 4088k will fail
 and pthread_sa_start() will call abort().
 
   The other architectures generall have a larger virtual address space
 for user processes and can take larger stacks.  The m68k architectures
 have varying virtual space configurations, and the ones using 4k pages
 with larger address spaces can panic on 68040 or 68060 cpus.
 
 >>Fix:
 > 	workaround: lower stacksize limit :-P
 
   USRSTACK in sys/arch/amiga/include/vmparam.h can be increased at
 the expense of more kernel memory used, and potentially allowing a
 user process to panic the system (at least until I fix the pmap
 limitations on the 68040/060).
 
 --
 Michael L. Hitch			mhitch@montana.edu
 Computer Consultant
 Information Technology Center
 Montana State University	Bozeman, MT	USA