Coda File System

Re: lwp 2.0 problem on FreeBSD?

From: Jan Harkes <>
Date: Mon, 20 Jun 2005 10:48:54 -0400
On Sun, Jun 19, 2005 at 04:28:40PM -0400, Ivan Popov wrote:
> for the latest coda-client-setup I have compiled lwp 2.0.
> To compile for Darwin I had to reverse some logic about using ucontext.h

Reverse what exactly, and could this reversal be related to the problems
you're seeing on FreeBSD?

> On FreeBSD the compilation succeded without tweaks but the resulting Venus
> randomly exit()ed without any reason or log messages,

Ok, there are 3 different methods to start a thread and 2 different ones
to perform a context switch.

Thread intialization (in order of preference)
    - makecontext		(ifdef HAVE_UCONTEXT_H)
    - sigaltstack		(ifdef HAVE_SIGALTSTACK)
    - old process.S assembly

Thread switching
    - swapcontext		(ifdef HAVE_UCONTEXT_H)
    - sigsetjmp/siglongjmp

> seemingly during some rpc2-activity, like probes or backprobes.

If the servers were considered unavailable, a probe will spawn a
separate thread for each server to set up a new connection. Once the
connection is initialized the threads commit 'suicide' returning.
According to the makecontext manpage we will then activate the
'successor context' which, in the case of LWP, is a special reaping
thread, that deallocates the thread structure and jumps into the

If the successor context is not defined, the manpage simply states that
the thread will 'exit'. This doesn't make much sense, but I found some
other manpage with google that stated that the if the successor is not
specified, the process should exit.

However since we always set the successor context, this exit case should
not be reached, so there must be some subtle implementation difference.
The ktrace seems to indicate that we just completed the probe, which
would be around the same time that the probeslave thread is done and

Did some googling and stumbled into the following which describes pretty
much the same problem,

I find the proposed solution pretty horrible, from my reading of the
ucontext documentation it seems like the contexts should be reusable in
these cases and I am clearly not the only one who thinks so.

After running configure, comment out '#define HAVE_UCONTEXT_H' in
config.h, does it work then? I might write a little testprogram for
configure to fall back on the alternative sigaltstack/setjmp/longjmp
implementation if that is the case.

Received on 2005-06-20 10:50:22