GDB and libthr

Daniel Eischen eischen at
Mon Oct 13 04:54:38 PDT 2003

On 13 Oct 2003, Doug Rabson wrote:

> I just upgraded one of my systems to the latest current and I came
> across some problems with libthr. A program which I was working on
> suddenly found itself linked against libthr (presumably because of a new
> version of libmap.conf or similar) and I found myself completely unable
> to debug it. This was not a threaded application, merely one which had
> linked against libthr.
> The symtoms are that when running the application under gdb, it quickly
> hangs and starts consuming as much CPU time as it can. I looked into
> things carefully and at the bottom of things, I discovered that when a
> libthr mutex is held, the process blocks out SIGTRAP (among other
> things). If the application hits a breakpoint while the mutex is held,
> everything quickly goes pear shaped since the application doesn't get
> the SIGTRAP. Basically it gets into a tight loop of hitting the
> breakpoint, getting a signal, ignoring it and then trying to execute the
> breakpoint instruction again.
> Since this also happens when dlopen is called (there is always a
> breakpoint inside the dynamic linker to keep GDB's list of shared
> libraries up to date) and since comon apis such as getpwuid end up in
> dlopen via nsdispatch, it becomes impossible to run many applications
> even without setting breakpoints.
> The simplest change which fixed things for me was to remove SIGTRAP from
> the list of signals blocked on mutex entry:

I don't maintain libthr, but this looks OK to me.

> Index: thr_kern.c
> ===================================================================
> RCS file: /home/ncvs/src/lib/libthr/thread/thr_kern.c,v
> retrieving revision 1.13
> diff -u -r1.13 thr_kern.c
> --- thr_kern.c	8 Jul 2003 09:58:23 -0000	1.13
> +++ thr_kern.c	12 Oct 2003 12:05:39 -0000
> @@ -80,6 +80,7 @@
>  #endif
>  	/* If we have already blocked signals, just up the refcount */
>  	if (++curthread->signest > 1)

Dan Eischen

More information about the freebsd-threads mailing list