From owner-freebsd-threads@FreeBSD.ORG Thu Sep 16 18:45:10 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D17D16A4CE for ; Thu, 16 Sep 2004 18:45:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A778643D39 for ; Thu, 16 Sep 2004 18:45:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 940E41FFDDC for ; Thu, 16 Sep 2004 20:45:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 894351FFDD6; Thu, 16 Sep 2004 20:45:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id B991615384; Thu, 16 Sep 2004 18:43:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id AEC5815380 for ; Thu, 16 Sep 2004 18:43:26 +0000 (UTC) Date: Thu, 16 Sep 2004 18:43:26 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: freebsd-threads@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Subject: assert in _lock_acquire ? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2004 18:45:10 -0000 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. 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 pthread = (struct pthread *) 0x80d7b80 #2 0x08075166 in mutex_unlock_common (m=0x8092d6c, add_reference=0) at /u1/src/src/RELENG_5/compile-20040914-1630/lib/libpthread/thread/thr_mutex.c:1026 curthread = (struct pthread *) 0x80ee000 kmbx = (struct kse_mailbox *) 0x0 ret = 0 #3 0x08074c24 in _pthread_mutex_unlock (m=0x8092d6c) at /u1/src/src/RELENG_5/compile-20040914-1630/lib/libpthread/thread/thr_mutex.c:879 No locals. .... #9 0x0806ed84 in thread_start (curthread=0x80ee000, start_routine=0x806d62c , arg=0x0) at /u1/src/src/RELENG_5/compile-20040914-1630/lib/libpthread/thread/thr_create.c:342 No locals. #10 0x2815dcbf in _ctx_start () from /lib/libc.so.5 No symbol table info available. ------ cut ------- it seems I am running into an assert() in _lock_acquire. does this make any sense ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT