On Tue, Apr 25, 2006 at 12:24:31PM -0400, Greg Troxel wrote:
>   One other thing I am interested in, what is the output of LWP's
>   configure. I wonder which type of thread switching it picked. I think
>   NetBSD deprecated makecontext and friends, so it might be using tricks
>   with signal handlers (sigaltstack) to kickstart new threads, or it could
>   be falling back on the old assembly code which might not realize that
>   this is a 32-bit kernel/userspace. So it could be that the first thread
>   switch is trying to perform a 64-bit read which triggers the bus error.
> 
> A very interesting possibility.
> 
> It would be cool to have a lwp-config program that outputs information
> about what it chose.  I think ucontext is being used.
...
> gdt-sparc64 86 ~/SOFTWARE/CODA/lwp/src > size *.o
...
>       0       0       0       0       0 liblwp_la-lwp_ucontext.o

Yeah, that is definitely using libc's ucontext implementation and not
any of my workarounds. My memory must be flaky and maybe it was FreeBSD
that dropped support for these. I remember reading somewhere that there
was some conflict between a C or POSIX standard and the prototypes used
by the ucontext interface and that pthread_create was considered a
better and more standard interface anyways (which is a fine idea if you
don't mind your threads being concurrent...)

> testlwp and rw both work, and tdb crashes:
> 
> gdt 89 ~/SOFTWARE/CODA/lwp/src > libtool gdb tdb
> *** Warning: inferring the mode of operation is deprecated.
> *** Future versions of Libtool will require --mode=MODE be specified.
> GNU gdb 5.3nb1
> Copyright 2002 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 "sparc64--netbsdelf"...
> (gdb) run
> Starting program: /usr/home/gdt/SOFTWARE/CODA/lwp/src/.libs/tdb 
> Main thread going to create procA
> Main thread going to create procB
> Main thread going to create procC 
> Main thread returned from creating procC  
> procA starting ...
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000040205cd8 in _rtld_symlook_list () from /usr/libexec/ld.elf_so

This is right before it would say,

    procA:please input a number

And it crashes in the dynamic loader, maybe it is trying to get the
symbol for scanf.

It looks like the size of the stack it allocates is really small. And
printf/scanf tend to be pretty stack hungry. I wouldn't be surprised if
either of them used at least 4KB or more as temporary buffer space.

Does the crash go away if you change

tdb.c:line 68
-   LWP_CreateProcess(procA, 2048, ...
+   LWP_CreateProcess(procA, 8192, ...

(and the same for procB and procC right below this one)

Jan