assert in _lock_acquire ?

Daniel Eischen deischen at freebsd.org
Thu Sep 16 12:34:12 PDT 2004


On Thu, 16 Sep 2004, Bjoern A. Zeeb wrote:

> Hi,
>
> I am using a global mutex to serialize a longer debugging
> output amongst threads. As this is only used for internal
> debugging builds where I really want to see everything
> I do not care about performance etc.

Where did you introduce the global mutex?  In your application
or in libpthread or libc sources?

> Recently I ran into problems with that - getting a core dump
> at the same place in this debugging function. It takes some
> time but I can always reproduce it.
>
> I have seen this the last weeks with at least HEAD/ULE and since
> yesterday with RELENG_5/4BSD. The first debugging log where I can
> find it is dated 20040802. At that time the machine must have
> been running a 5-CURRENT from around 20040625.
>
> So I finally built libpthread with
> 	env DEBUG_FLAGS=-g make all
> and even linked with libpthread.a instead of using the shared lib.
>
> Here's the relevant part of the backtrace:
>
> ------ cut -------
> (gdb) bt full
> #0  _lock_acquire (lck=0x38, lu=0x80da034, prio=56) at /u1/src/src/RELENG_5/compile-20040914-1630/lib/libpthread/sys/lock.c:168
>         i = 135110708
>         lval = 672675788
>         __func__ = "_lock_acquire"
> #1  0x08076151 in mutex_handoff (curthread=0x80ee000, mutex=0x80d8980) at /u1/src/src/RELENG_5/compile-20040914-1630/lib/libpthread/thread/thr_mutex.c:1586
>         kmbx = (struct kse_mailbox *) 0x1

The kse_mailbox has become corrupted.  If you are using %gs for anything,
that could be the cause.  %gs is reserved for the threads libraries.

-- 
Dan Eischen



More information about the freebsd-threads mailing list