From owner-freebsd-threads@FreeBSD.ORG Mon Sep 10 11:08:25 2007 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10BDE16A46C for ; Mon, 10 Sep 2007 11:08:25 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D067513C4A5 for ; Mon, 10 Sep 2007 11:08:24 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8AB8Oji017424 for ; Mon, 10 Sep 2007 11:08:24 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8AB8NI5017420 for freebsd-threads@FreeBSD.org; Mon, 10 Sep 2007 11:08:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Sep 2007 11:08:23 GMT Message-Id: <200709101108.l8AB8NI5017420@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 11:08:25 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for -lc_r 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/20016 threads pthreads: Cannot set scheduling timer/Cannot set virtu s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s bin/32295 threads pthread dont dequeue signals s threa/34536 threads accept() blocks other threads o kern/38549 threads the procces compiled whith pthread stopped in pthread_ s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/49087 threads Signals lost in programs linked with libc_r s kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOC o threa/70975 threads unexpected and unreliable behaviour when using SYSV se o threa/72429 threads threads blocked in stdio (fgets, etc) are not cancella o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag s threa/76694 threads fork cause hang in dup()/close() function in child (-l o threa/79683 threads svctcp_create() fails if multiple threads call at the o threa/80435 threads panic on high loads o threa/83914 threads [libc] popen() doesn't work in static threaded program s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/85160 threads [libthr] [patch] libobjc + libpthread/libthr crash pro o kern/91266 threads [threads] Trying sleep, but thread marked as sleeping s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/110636 threads gdb(1): using gdb with multi thread application with l o threa/113666 threads misc/shared-mime-info doesn't install, can't find thre 28 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19247 threads uthread_sigaction.c does not do anything wrt SA_NOCLDW s kern/22190 threads A threaded read(2) from a socketpair(2) fd can sometim s threa/30464 threads pthread mutex attributes -- pshared s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/69020 threads pthreads library leaks _gc_mutex o threa/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/81534 threads [libc_r] [patch] libc_r close() will fail on any fd ty o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/114982 threads threads sends error messages to stdout o threa/115211 threads pthread_atfork misbehaves in initial thread 12 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue Sep 11 01:36:53 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE15216A41B; Tue, 11 Sep 2007 01:36:53 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C6D6A13C46E; Tue, 11 Sep 2007 01:36:53 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8B1arNt081284; Tue, 11 Sep 2007 01:36:53 GMT (envelope-from davidxu@freefall.freebsd.org) Received: (from davidxu@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8B1arce081280; Tue, 11 Sep 2007 01:36:53 GMT (envelope-from davidxu) Date: Tue, 11 Sep 2007 01:36:53 GMT Message-Id: <200709110136.l8B1arce081280@freefall.freebsd.org> To: stephen@math.missouri.edu, davidxu@FreeBSD.org, freebsd-threads@FreeBSD.org From: davidxu@FreeBSD.org Cc: Subject: Re: threads/114982: threads sends error messages to stdout X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 01:36:54 -0000 Synopsis: threads sends error messages to stdout State-Changed-From-To: open->closed State-Changed-By: davidxu State-Changed-When: Tue Sep 11 01:36:24 UTC 2007 State-Changed-Why: Fixed. http://www.freebsd.org/cgi/query-pr.cgi?pr=114982 From owner-freebsd-threads@FreeBSD.ORG Fri Sep 14 00:12:55 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98CFF16A41A for ; Fri, 14 Sep 2007 00:12:55 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from shadow.wildlava.net (shadow.wildlava.net [67.40.138.81]) by mx1.freebsd.org (Postfix) with ESMTP id 67DD113C468 for ; Fri, 14 Sep 2007 00:12:55 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from [67.40.138.82] (crater.wildlava.net [67.40.138.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shadow.wildlava.net (Postfix) with ESMTP id 5F7A98F431 for ; Thu, 13 Sep 2007 17:46:18 -0600 (MDT) Message-ID: <46E9CBC8.3060906@gentoo.org> Date: Thu, 13 Sep 2007 17:46:16 -0600 From: Joe Peterson User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Segfault when mapping libpthread -> libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 00:12:55 -0000 I am a developer on the Gentoo/FreeBSD project. For those who don't know, this is basically porting the gentoo tools, package installer, init stuff, etc. to FreeBSD (kernel and userland). I have been investigating a rather challenging crash in libthr with 6.2. We have libpthread and libc_r mapped to libthr (as I understand this is the default for 7.0). I doubt, however, that this issue is gentoo-related, since the system is essentially FreeBSD, but I cannot be 100% sure, of course. In particular, ImageMagick's "mogrify" utility is segfaulting. I have traced this down to the fact that _cur_thread() returns a different address after many mutex locks in pthread (using the libthr library). This causes the mutex linked list in the thread to have zero pointers for first/last, and the crash results. I have verified with a ImageMagick developer that mogrfiy is using only one thread, so this should never happen. Another clue is that the curthread address seems to change sometime shortly before __error (in libthr/sys/thr_error.c) gets called. I now am not sure how to debug this further. The address returned by _get_curthread() is close, but slightly higher (by typically 0x100) than the original thread's address. I can reproduce the problem faithfully on two of my systems, so if any of this rings a bell, or if you have any suggestions for things to try on my end, I'd be extremely appreciative! -Joe From owner-freebsd-threads@FreeBSD.ORG Fri Sep 14 01:47:38 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8148116A418 for ; Fri, 14 Sep 2007 01:47:38 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6BFE613C458; Fri, 14 Sep 2007 01:47:38 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8E1lZwW043755; Fri, 14 Sep 2007 01:47:37 GMT (envelope-from davidxu@freebsd.org) Message-ID: <46E9E867.7030909@freebsd.org> Date: Fri, 14 Sep 2007 09:48:23 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Peterson References: <46E9CBC8.3060906@gentoo.org> In-Reply-To: <46E9CBC8.3060906@gentoo.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: Segfault when mapping libpthread -> libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 01:47:38 -0000 Joe Peterson wrote: > I am a developer on the Gentoo/FreeBSD project. For those who don't > know, this is basically porting the gentoo tools, package installer, > init stuff, etc. to FreeBSD (kernel and userland). I have been > investigating a rather challenging crash in libthr with 6.2. We have > libpthread and libc_r mapped to libthr (as I understand this is the > default for 7.0). I doubt, however, that this issue is gentoo-related, > since the system is essentially FreeBSD, but I cannot be 100% sure, of > course. > > In particular, ImageMagick's "mogrify" utility is segfaulting. I have > traced this down to the fact that _cur_thread() returns a different > address after many mutex locks in pthread (using the libthr library). > This causes the mutex linked list in the thread to have zero pointers > for first/last, and the crash results. I have verified with a > ImageMagick developer that mogrfiy is using only one thread, so this > should never happen. > > Another clue is that the curthread address seems to change sometime > shortly before __error (in libthr/sys/thr_error.c) gets called. > > I now am not sure how to debug this further. The address returned by > _get_curthread() is close, but slightly higher (by typically 0x100) than > the original thread's address. > > I can reproduce the problem faithfully on two of my systems, so if any > of this rings a bell, or if you have any suggestions for things to try > on my end, I'd be extremely appreciative! > > -Joe you may try revision 1.3 of http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libthr/sys/thr_error.c to see if the problem goes away. David Xu From owner-freebsd-threads@FreeBSD.ORG Fri Sep 14 04:43:49 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D438316A420; Fri, 14 Sep 2007 04:43:49 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from shadow.wildlava.net (shadow.wildlava.net [67.40.138.81]) by mx1.freebsd.org (Postfix) with ESMTP id A39D613C469; Fri, 14 Sep 2007 04:43:49 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from [10.1.2.160] (pawnee.wildlava.net [67.40.138.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shadow.wildlava.net (Postfix) with ESMTP id DAB738F431; Thu, 13 Sep 2007 22:43:48 -0600 (MDT) Message-ID: <46EA0365.6070800@gentoo.org> Date: Thu, 13 Sep 2007 21:43:33 -0600 From: Joe Peterson User-Agent: Thunderbird 2.0.0.6 (X11/20070816) MIME-Version: 1.0 To: David Xu References: <46E9CBC8.3060906@gentoo.org> <46E9E867.7030909@freebsd.org> In-Reply-To: <46E9E867.7030909@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: Segfault when mapping libpthread -> libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 04:43:49 -0000 David Xu wrote: > Joe Peterson wrote: >> I am a developer on the Gentoo/FreeBSD project. For those who don't >> know, this is basically porting the gentoo tools, package installer, >> init stuff, etc. to FreeBSD (kernel and userland). I have been >> investigating a rather challenging crash in libthr with 6.2. We have >> libpthread and libc_r mapped to libthr (as I understand this is the >> default for 7.0). I doubt, however, that this issue is gentoo-related, >> since the system is essentially FreeBSD, but I cannot be 100% sure, of >> course. >> >> In particular, ImageMagick's "mogrify" utility is segfaulting. I have >> traced this down to the fact that _cur_thread() returns a different >> address after many mutex locks in pthread (using the libthr library). >> This causes the mutex linked list in the thread to have zero pointers >> for first/last, and the crash results. I have verified with a >> ImageMagick developer that mogrfiy is using only one thread, so this >> should never happen. >> >> Another clue is that the curthread address seems to change sometime >> shortly before __error (in libthr/sys/thr_error.c) gets called. >> >> I now am not sure how to debug this further. The address returned by >> _get_curthread() is close, but slightly higher (by typically 0x100) than >> the original thread's address. >> >> I can reproduce the problem faithfully on two of my systems, so if any >> of this rings a bell, or if you have any suggestions for things to try >> on my end, I'd be extremely appreciative! >> >> -Joe > you may try revision 1.3 of > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libthr/sys/thr_error.c > to see if the problem goes away. Nope, still same result. The call to __error() doesn't happen until quite a few _get_curthread() calls happen and many mutex's get locked/unlocked, so I was not optimistic this would fix it. -Joe From owner-freebsd-threads@FreeBSD.ORG Fri Sep 14 20:10:36 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A53816A417; Fri, 14 Sep 2007 20:10:36 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from shadow.wildlava.net (shadow.wildlava.net [67.40.138.81]) by mx1.freebsd.org (Postfix) with ESMTP id 673B313C461; Fri, 14 Sep 2007 20:10:36 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from [67.40.138.82] (crater.wildlava.net [67.40.138.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shadow.wildlava.net (Postfix) with ESMTP id A41E18F428; Fri, 14 Sep 2007 14:10:35 -0600 (MDT) Message-ID: <46EAEABA.20003@gentoo.org> Date: Fri, 14 Sep 2007 14:10:34 -0600 From: Joe Peterson User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: David Xu References: <46E9CBC8.3060906@gentoo.org> <46E9E867.7030909@freebsd.org> In-Reply-To: <46E9E867.7030909@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: Segfault when mapping libpthread -> libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 20:10:36 -0000 Update: Upon investigating what code could possibly change %%gs, which holds curthread (I am on i386 arch), the only other candidate, of course, was libpthread itself, which is mapped to libthr by libmap.conf (thereby hopefully causing it to not be used). But to test this, I temporarily removed libpthread.so (link) from /usr/lib. This actually made the problem disappear! So it appears that both libthr and libpthread are being used by mogrify or its libs, which now would explain the crash. I assume libpthread grabbed a new thread address and updated curthread out from under libthr. So the question now (which I am currently investigting) is how could this happen? I have used ldd to examine the binaries and all libs, and they all show libpthread mapped to libthr. I do not know of a way for libmap.conf to be bypassed (someone suggested a hard-coded lib file/path). If anyone has ideas, please let me know. Otherwise I'll keep plugging away at this and report the results when I figure it out. Thanks, Joe David Xu wrote: > Joe Peterson wrote: >> I am a developer on the Gentoo/FreeBSD project. For those who don't >> know, this is basically porting the gentoo tools, package installer, >> init stuff, etc. to FreeBSD (kernel and userland). I have been >> investigating a rather challenging crash in libthr with 6.2. We have >> libpthread and libc_r mapped to libthr (as I understand this is the >> default for 7.0). I doubt, however, that this issue is gentoo-related, >> since the system is essentially FreeBSD, but I cannot be 100% sure, of >> course. >> >> In particular, ImageMagick's "mogrify" utility is segfaulting. I have >> traced this down to the fact that _cur_thread() returns a different >> address after many mutex locks in pthread (using the libthr library). >> This causes the mutex linked list in the thread to have zero pointers >> for first/last, and the crash results. I have verified with a >> ImageMagick developer that mogrfiy is using only one thread, so this >> should never happen. >> >> Another clue is that the curthread address seems to change sometime >> shortly before __error (in libthr/sys/thr_error.c) gets called. >> >> I now am not sure how to debug this further. The address returned by >> _get_curthread() is close, but slightly higher (by typically 0x100) than >> the original thread's address. >> >> I can reproduce the problem faithfully on two of my systems, so if any >> of this rings a bell, or if you have any suggestions for things to try >> on my end, I'd be extremely appreciative! >> >> -Joe > you may try revision 1.3 of > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libthr/sys/thr_error.c > to see if the problem goes away. > > David Xu > From owner-freebsd-threads@FreeBSD.ORG Fri Sep 14 23:13:46 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EF1516A419 for ; Fri, 14 Sep 2007 23:13:46 +0000 (UTC) (envelope-from gofdt-freebsd-threads@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3C27A13C467 for ; Fri, 14 Sep 2007 23:13:46 +0000 (UTC) (envelope-from gofdt-freebsd-threads@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IWJW6-0000fs-Ro for freebsd-threads@freebsd.org; Sat, 15 Sep 2007 00:20:02 +0200 Received: from 78-0-71-165.adsl.net.t-com.hr ([78.0.71.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Sep 2007 00:20:02 +0200 Received: from ivoras by 78-0-71-165.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Sep 2007 00:20:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-threads@freebsd.org From: Ivan Voras Date: Fri, 14 Sep 2007 23:12:31 +0200 Lines: 35 Message-ID: References: <46E9CBC8.3060906@gentoo.org> <46E9E867.7030909@freebsd.org> <46EAEABA.20003@gentoo.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4DCEDDAA498BD7674D09F777" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-71-165.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <46EAEABA.20003@gentoo.org> X-Enigmail-Version: 0.95.3 Sender: news Subject: Re: Segfault when mapping libpthread -> libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 23:13:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4DCEDDAA498BD7674D09F777 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joe Peterson wrote: > So the question now (which I am currently investigting) is how could > this happen? I have used ldd to examine the binaries and all libs, and= > they all show libpthread mapped to libthr. I do not know of a way for > libmap.conf to be bypassed (someone suggested a hard-coded lib > file/path). If anyone has ideas, please let me know. Otherwise I'll > keep plugging away at this and report the results when I figure it out.= Hmmm, maybe static linkage of libpthread? But why would anyone do such a thing? --------------enig4DCEDDAA498BD7674D09F777 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6vlGldnAQVacBcgRAv5EAJsGgBCxrXMq0wiyvjkkfGhDa0M6OQCdHGXZ wsxqdiUK8piWjivYGCnGrJE= =JHbR -----END PGP SIGNATURE----- --------------enig4DCEDDAA498BD7674D09F777-- From owner-freebsd-threads@FreeBSD.ORG Fri Sep 14 23:22:43 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E5A216A419 for ; Fri, 14 Sep 2007 23:22:43 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from shadow.wildlava.net (shadow.wildlava.net [67.40.138.81]) by mx1.freebsd.org (Postfix) with ESMTP id 3399613C461 for ; Fri, 14 Sep 2007 23:22:43 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from [10.1.2.161] (pawnee.wildlava.net [67.40.138.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shadow.wildlava.net (Postfix) with ESMTP id 4BE528F436; Fri, 14 Sep 2007 17:22:42 -0600 (MDT) Message-ID: <46EB17B0.2060507@gentoo.org> Date: Fri, 14 Sep 2007 17:22:24 -0600 From: Joe Peterson User-Agent: Thunderbird 2.0.0.6 (X11/20070816) MIME-Version: 1.0 To: Ivan Voras References: <46E9CBC8.3060906@gentoo.org> <46E9E867.7030909@freebsd.org> <46EAEABA.20003@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: Segfault when mapping libpthread -> libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 23:22:43 -0000 Ivan Voras wrote: > Joe Peterson wrote: > >> So the question now (which I am currently investigting) is how could >> this happen? I have used ldd to examine the binaries and all libs, and >> they all show libpthread mapped to libthr. I do not know of a way for >> libmap.conf to be bypassed (someone suggested a hard-coded lib >> file/path). If anyone has ideas, please let me know. Otherwise I'll >> keep plugging away at this and report the results when I figure it out. > > Hmmm, maybe static linkage of libpthread? But why would anyone do such a > thing? Yeah, that would be strange. But when I move libpthread.so out of the way, the crash stops happening, so I assume it's dynamically referencing it. Strangely, it doesn't complain when I move it, so it's as if something is grabbing libpthread.so if it's there but falling back to something else (I assume libthr.so) if not. Here's the output of ldd /usr/bin/mogrify: /usr/bin/mogrify: libMagick.so.10 => /usr/lib/libMagick.so.10 (0x28086000) libWand.so.10 => /usr/lib/libWand.so.10 (0x2826c000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x2832b000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x2837f000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x2839e000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x283c9000) libpthread.so.2 => /usr/lib/libthr.so.2 (0x284eb000) libiconv.so.2 => /lib/libiconv.so.2 (0x284fd000) libXext.so.6 => /usr/lib/libXext.so.6 (0x285db000) libXt.so.6 => /usr/lib/libXt.so.6 (0x285e9000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x28638000) libz.so.1 => /lib/libz.so.1 (0x286b3000) libSM.so.6 => /usr/lib/libSM.so.6 (0x286c5000) libICE.so.6 => /usr/lib/libICE.so.6 (0x286ce000) libX11.so.6 => /usr/lib/libX11.so.6 (0x286e5000) libXau.so.6 => /usr/lib/libXau.so.6 (0x287d0000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x287d3000) librpcsvc.so.3 => /usr/lib/librpcsvc.so.3 (0x287d8000) libm.so.4 => /lib/libm.so.4 (0x287e0000) libc.so.6 => /lib/libc.so.6 (0x287f6000) libgcc_s.so.1 => /usr/lib/gcc/i686-gentoo-freebsd6.2/4.2.0/libgcc_s.so.1 (0x288e0000) Note that the only reference to threads is the redirection from libmap.conf of libpthread -> libthr... So I cannot see how anything would pick up the real libpthread. -Joe From owner-freebsd-threads@FreeBSD.ORG Fri Sep 14 23:29:35 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4615016A417; Fri, 14 Sep 2007 23:29:35 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0EE13C45E; Fri, 14 Sep 2007 23:29:34 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [192.168.168.201] (canonware.com [64.183.146.166]) by canonware.com (Postfix) with ESMTP id 6EB3F129821; Fri, 14 Sep 2007 16:17:24 -0700 (PDT) Message-ID: <46EB152B.1080905@freebsd.org> Date: Fri, 14 Sep 2007 16:11:39 -0700 From: Jason Evans User-Agent: Thunderbird 1.5.0.12 (X11/20070718) MIME-Version: 1.0 To: Joe Peterson References: <46E9CBC8.3060906@gentoo.org> <46E9E867.7030909@freebsd.org> <46EAEABA.20003@gentoo.org> In-Reply-To: <46EAEABA.20003@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Xu , freebsd-threads@freebsd.org Subject: Re: Segfault when mapping libpthread -> libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 23:29:35 -0000 Joe Peterson wrote: > Update: Upon investigating what code could possibly change %%gs, which > holds curthread (I am on i386 arch), the only other candidate, of > course, was libpthread itself, which is mapped to libthr by libmap.conf > (thereby hopefully causing it to not be used). > > But to test this, I temporarily removed libpthread.so (link) from > /usr/lib. This actually made the problem disappear! So it appears that > both libthr and libpthread are being used by mogrify or its libs, which > now would explain the crash. I assume libpthread grabbed a new thread > address and updated curthread out from under libthr. > > So the question now (which I am currently investigting) is how could > this happen? I have used ldd to examine the binaries and all libs, and > they all show libpthread mapped to libthr. I do not know of a way for > libmap.conf to be bypassed (someone suggested a hard-coded lib > file/path). If anyone has ideas, please let me know. Otherwise I'll > keep plugging away at this and report the results when I figure it out. I saw something similar a while back when investigating malloc problem reports (that turned out to be a threads problem). It looked to me like there was a minor incompatibility in the exported symbols of libpthread and libthr that caused rtld to pull some symbols from libpthread, despite the libmap.conf settings. IIRC, the symbol incompatibilities did not at first glance seem like they would cause the problem, but my guess (unverified) was that dynamic dependency resolution was chasing a dependency into libpthread before a legitimate dependency through libthr managed to map the symbol. I'm sorry that I don't remember the nature of the library interface incompatibilities. It seems to me though that it was pretty subtle, having to do with weak internally exported symbols (available to other .o's within the library, but not to external consumers of the library). Jason