[MUD-Dev] Re: LinuxThreads and SIGUSR1 (Ref: [MUD-Dev])

["Adam J. Thornton" <adam#phoenix,Princeton.EDU>]

On Wed, Aug 12, 1998 at 03:18:53PM -0600, Lucas Thompson wrote:
> At 12:35 PM -0600 8/12/1998, Adam J. Thornton wrote:
> > An unrelated problem, but a very annoying one.  I'm new to Linux threads
> > programming.  I'm using RH5.1.  When I call pthread_create() I get the new
> > thread, but also a SIGUSR1.  If I don't SIG_IGN it, the program exits (this
> > is default behavior for SIGUSR1).  But if I *do* ignore it, then the
> > process never returns from the thread creation.  Did I miss something
> > really obvious here?
> Odd, I do SIG_IGN our USR1/USR2 signals, but back when I was first adding
> our threaded I/O and dns code I don't remember the process exiting when it
> got USR1 (back before we added signal handling to our mud). I may be wrong,
> it's been a year or so. Are you compiling with -D_REENTRANT? Linking with
> pthreads without defining _REENTRANT is a Bad Thing(tm) because your IO
> calls will lose their 'errno' and frequently exit falsely even when nothing
> went wrong.

Ah.  A little more digging with a thread-enabled debugger helped.

SIGUSR1 and SIGUSR2 are indeed used by Linuxthreads, but what was actually
killing me was a SIGSEGV.  And that...was because I was passing a NULL
pointer to pthread_create as its first argument.  Why, you might ask, was I
doing that?  Well, because that's what Stevens did.  But it's wrong.
Allocate some space for the pthread_t pointer and pass it, and it works
fine.  

I'll send him a bug report.

Adam
-- 
adam#princeton,edu 
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman