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