Elliot,

This is indeed bad news.  And even worse is the news that we have no
cycles at the moment to switch to egcs. 

The first suspect is the stacksize of that thread in which you crash. I'd
do something like:

p *lwp_cpptr

in gdb and find out what the allocated stack is and print what your
current stack pointer is.  If egcs uses bigger stacks we have a minor
problem. You might have thread stack overflow.  

The weird problems you have really point to something like this.

- Peter -

On Tue, 3 Feb 1998, Elliot Lee wrote:

> As your official harbinger of bad tidings, I feel obligated to bring you
> this message of destruction... ;-)
> 
> At least it doesn't segv in the same place as before...
> 
> (gdb) run
> Starting program: /usr/sbin/venus 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x4011518c in __libc_internal_tsd_get () at specific.c:157
> specific.c:157: No such file or directory.
> Current language:  auto; currently c
> (gdb) where
> #0  0x4011518c in __libc_internal_tsd_get () at specific.c:157
> #1  0x400aa5b4 in malloc () at malloc.c:2349
> #2  0x8056791 in RegisterDaemon (interval=5, sync=0x821a794 "")
>     at ../../../coda-4.3.13/coda-src/venus/daemon.cc:104
> #3  0x80b2589 in RecovDaemon ()
>     at ../../../coda-4.3.13/coda-src/venus/venusrecov.cc:897
> #4  0x80eade7 in VprocPreamble (init_lock=0x822cb90)
>     at ../../../coda-4.3.13/coda-src/venus/vproc.cc:173
> #5  0x8117df9 in Create_Process_Part2 ()
>     at ../../../coda-4.3.13/lib-src/mlwp/lwp.c:1064
> #6  0x8118f1f in L1 () at
> ../../../coda-4.3.13/coda-src/venus/vol_repair.cc:136
> #7  0xf4d83d80 in ?? ()
> 
> -- Elliot
> Will read UCE for food! Charge of only $500 per message received. ;-) 
> 
>