Coda File System

Re: latest sources fail on NetBSD 2.99.15

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Mon, 27 Jun 2005 14:50:47 -0400
On Mon, Jun 27, 2005 at 01:46:36PM -0400, Greg Troxel wrote:
> Two problems:
> 
>   vice/srv.cc fails to compile because it uses struct sigcontext,
>   which NetBSD no longer defines.  Use ucontext instead is the vibe I
>   get from googling.  This isn't a BSD44 feature so shouldn't be
>   ifdefed on that, but perhaps on HAVE_SIGCONTEXT, but I think
>   ucontext is the way to go.  quagga has code to do backtraces and it
>   does something useful on NetBSD and may be useful for reference.

It doesn't look like we actually use the context we're saving. It might
be for debugging purposes, but once we trap it in the debugger the info
should be accessible even if we don't make the copy to OldContext.

If the information is useful, it is probably better to use sigaction
with the SA_SIGINFO flag set, which is defined by POSIX.

>   venus segvs on startup (venus -init after removing rvm).
>   This is in lwp_DispatchProcess, with RecovDaemon, line 789.  This is
>   checking for a stack guardword (right hand side of second test is 0,
>   so failing.  I don't get why it is segfaulting though.

Interesting, that is the first thread that is started, so something must
be wrong in the way LWP sets up the initial ucontext. As far as I can
see, the main thread doesn't have a fixed stack, but in that case
stackcheck should be 0. All the other threads have malloced stacks and
stackcheck will contain a copy of the word that is on the bottom.

This is used so that when that word is clobbered while the stack grows
down (and doesn't trigger a segfault/buserror on accessing an unmapped
page right below the stack), we would catch it as soon as we call into
DispatchProcess.

It could be segfaulting if this is the main process thread, which
doesn't have a dynamic stack and uc_stack.ss_sp == NULL.

Jan
Received on 2005-06-27 14:52:01