Date: Thu, 13 Sep 2007 21:43:33 -0600 From: Joe Peterson <lavajoe@gentoo.org> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: Segfault when mapping libpthread -> libthr Message-ID: <46EA0365.6070800@gentoo.org> In-Reply-To: <46E9E867.7030909@freebsd.org> References: <46E9CBC8.3060906@gentoo.org> <46E9E867.7030909@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46EA0365.6070800>