On Tue, May 30, 2000 at 12:13:29AM -0400, ww_at_shadowfax.styx.org wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
> 
> >>>>> "WW" == ww  <ww_at_shadowfax.styx.org> writes:
> 
>     WW> 1.4.1 seems to have  support for coda on certain architectures
>     WW> (i386), but not on  sparc. After adding an entry for character
>     WW> major number 62 in sys/arch/sparc/sparc/conf.c I can get venus
>     WW> to run, but it dumps core fairly early on. It seems that venus
>     WW> disables  core dumps,  so I'll probably  have to modify  it to
>     WW> disable this  to get more debugging information.
> 
> I've  done this  now, and  it seems  to be  a problem  in  the threads
> library: 
> 
> (gdb) run
> Starting program: /tmp/venus 
> Coda Venus, version 5.3.5
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x101d3c78 in savecontext ()
> (gdb) bt
> #0  0x101d3c78 in savecontext ()
> #1  0x101d2634 in InitializeProcessSupport ()
> #2  0x101d2484 in LWP_Init ()
> #3  0xcd244 in vproc::start_thread (this=0x1c7000) at vproc.cc:421

Is this a shared library? There is some assembly code that only works
correctly on i386 (and maybe PPC) when dynamically linked. Current
versions of LWP should be avoiding to build the shared library on
anything but i386 platforms. (configure --disable-shared)

I've got an idea of what causes it, the PRE_Block global variable to be
precise, but haven't yet tried if that actually fixes the problem.

Jan