From owner-freebsd-current@FreeBSD.ORG Fri May 9 17:16:36 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FC1F37B401 for ; Fri, 9 May 2003 17:16:36 -0700 (PDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42D2943FB1 for ; Fri, 9 May 2003 17:16:35 -0700 (PDT) (envelope-from marcus@marcuscom.com) Received: from mail3.nc.rr.com (fe3 [24.93.67.50])h4A0EHgu026215 for ; Fri, 9 May 2003 20:14:17 -0400 (EDT) Received: from creme-brulee.marcuscom.com ([66.57.17.158]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 9 May 2003 20:13:38 -0400 Received: from shumai.marcuscom.com (shumai.marcuscom.com [192.168.1.4]) h4A0Cdaa084601 for ; Fri, 9 May 2003 20:12:39 -0400 (EDT) (envelope-from marcus@marcuscom.com) X-Authentication-Warning: creme-brulee.marcuscom.com: shumai.marcuscom.com [192.168.1.4] didn't use HELO protocol From: Joe Marcus Clarke To: current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NBq6O8G1s4gB1WTBYrH+" Organization: MarcusCom, Inc. Message-Id: <1052525788.89237.8.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.3 (Preview Release) Date: 09 May 2003 20:16:28 -0400 X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,PGP_SIGNATURE_2 autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: Bug on libc_r? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2003 00:16:36 -0000 --=-NBq6O8G1s4gB1WTBYrH+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Users testing the GNOME 2.3.x snapshots recently ran into a strange crash in Nautilus. I updated my own -CURRENT machine, and found the problem is quite reproduceable. I'm still trying to track down why this suddenly started happening, but it looks like there might be a bug in libc_r on -CURRENT. This problem is not seen on -STABLE with the same version of Nautilus and dependent libraries. The version of -CURRENT in question is: FreeBSD jclarke-pc.cisco.com 5.1-BETA FreeBSD 5.1-BETA #15: Thu May 8 12:45:49 EDT 2003 =20 marcus@jclarke-pc.cisco.com:/usr/obj/usr/src/sys/JCLARKE-PC i386 The stack trace with thread locking debugging enabled is: Program received signal SIGSEGV, Segmentation fault. _atomic_lock () at {standard input}:15 15 {standard input}: No such file or directory. in {standard input} Current language: auto; currently asm #0 _atomic_lock () at {standard input}:15 #1 0x28de9f44 in _spinlock_debug (lck=3D0x28a15678, fname=3D0x1 , lineno=3D-1078989016) at /usr/src/lib/libc_r/uthread/uthread_spinlock.c:110 #2 0x28defbf4 in mutex_unlock_common (mutex=3D0x28a15678, add_reference=3D1) at /usr/src/lib/libc_r/uthread/uthread_mutex.c:851 #3 0x28defa89 in _mutex_cv_unlock (mutex=3D0x1) at /usr/src/lib/libc_r/uthread/uthread_mutex.c:756 #4 0x28df4ae1 in _pthread_cond_wait (cond=3D0x28a15678, mutex=3D0x28a15678= ) at /usr/src/lib/libc_r/uthread/uthread_cond.c:254 #5 0x28df4c4e in __pthread_cond_wait (cond=3D0x1, mutex=3D0x1) at /usr/src/lib/libc_r/uthread/uthread_cond.c:343 #6 0x28d46595 in pthread_cond_wait () from /usr/lib/libc.so.5 #7 0x28a05a98 in gnome_vfs_thread_pool_wait_for_work (state=3D0x8400560) at gnome-vfs-thread-pool.c:152 #8 0x28a05af3 in thread_entry (cast_to_state=3D0x8400560) at gnome-vfs-thread-pool.c:172 #9 0x28b0acb2 in g_thread_create_proxy () from /usr/local/lib/libglib-2.0.so.200 #10 0x28de848e in _thread_start () at /usr/src/lib/libc_r/uthread/uthread_create.c:275 With thread locking debugging disabled, I get: Program received signal SIGSEGV, Segmentation fault. _atomic_lock () at {standard input}:15 15 {standard input}: No such file or directory. in {standard input} Current language: auto; currently asm (gdb) bt #0 _atomic_lock () at {standard input}:15 #1 0x28de9ba9 in _spinlock (lck=3D0x3957c) at /usr/src/lib/libc_r/uthread/uthread_spinlock.c:71 #2 0x28def742 in mutex_unlock_common (mutex=3D0x28a15678, add_reference=3D1) at /usr/src/lib/libc_r/uthread/uthread_mutex.c:851 #3 0x28def5e9 in _mutex_cv_unlock (mutex=3D0x1) at /usr/src/lib/libc_r/uthread/uthread_mutex.c:756 #4 0x28df430f in _pthread_cond_wait (cond=3D0x28a15678, mutex=3D0x28a15678= ) at /usr/src/lib/libc_r/uthread/uthread_cond.c:254 #5 0x28df446e in __pthread_cond_wait (cond=3D0x1, mutex=3D0x1) at /usr/src/lib/libc_r/uthread/uthread_cond.c:343 #6 0x28d46595 in pthread_cond_wait () from /usr/lib/libc.so.5 #7 0x28a05a98 in gnome_vfs_thread_pool_wait_for_work (state=3D0x8400560) at gnome-vfs-thread-pool.c:152 #8 0x28a05af3 in thread_entry (cast_to_state=3D0x8400560) at gnome-vfs-thread-pool.c:172 #9 0x28b0acb2 in g_thread_create_proxy () from /usr/local/lib/libglib-2.0.so.200 #10 0x28de82fe in _thread_start () at /usr/src/lib/libc_r/uthread/uthread_create.c:275 (gdb) frame 1 #1 0x28de9ba9 in _spinlock (lck=3D0x3957c) at /usr/src/lib/libc_r/uthread/uthread_spinlock.c:71 71 _thread_kern_sched_state(PS_SPINBLOCK, __FILE__, __LINE__); Current language: auto; currently c (gdb) print lck $1 =3D (struct {...} *) 0x3957c (gdb) print *lck Error accessing memory address 0x3957c: Bad address. Any idea if this is something in the GNOME stuff or in libc_r itself?=20 Thanks. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-NBq6O8G1s4gB1WTBYrH+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQA+vETcb2iPiv4Uz4cRAqdpAKCpu1Q9NPoyg/G3guDQBQZSrYRVuwCffDjf WUhtUNeweNkUxJC54atxz48= =XQbF -----END PGP SIGNATURE----- --=-NBq6O8G1s4gB1WTBYrH+--