From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 12 10:29:36 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 865D637B401 for ; Sat, 12 Jul 2003 10:29:36 -0700 (PDT) Received: from adsl-64-161-78-226.dsl.lsan03.pacbell.net (adsl-64-161-78-226.dsl.lsan03.pacbell.net [64.161.78.226]) by mx1.FreeBSD.org (Postfix) with SMTP id C4E8543F85 for ; Sat, 12 Jul 2003 10:29:35 -0700 (PDT) (envelope-from oremanj@adsl-64-161-78-226.dsl.lsan03.pacbell.net) Received: (qmail 31982 invoked by uid 1001); 12 Jul 2003 17:29:49 -0000 Date: Sat, 12 Jul 2003 10:29:49 -0700 From: Joshua Oreman To: deischen@freebsd.org Message-ID: <20030712172948.GC25971@webserver.get-linux.org> References: <20030712055248.GA23189@webserver.get-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: hackers@freebsd.org Subject: Re: getpwnam + getpwnam_r + LinuxThreads port = deadlock X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2003 17:29:36 -0000 On Sat, Jul 12, 2003 at 10:47:50AM -0400 or thereabouts, Daniel Eischen wrote: > On Fri, 11 Jul 2003, Joshua Oreman wrote: > > > Hi -hackers, > > > > System: FreeBSD 5.0-CURRENT cvsupped around 5.0-RELEASE > > > > I'm writing an app that links with the LinuxThreads > > (/usr/ports/devel/linuxthreads) and also uses getpwnam(). The problem: > > a deadlock. GDB backtrace: > > > > Basically: FreeBSD implements getpwnam() as a wrapper around > > getpwnam_r(), as seen in src/lib/libc/gen/getpwent.c: > > > > So basically, my app calls getpwnam(), which calls the overridden > > getpwnam_r() from LinuxThreads, which calls getpwnam() from libc > > again, and then calls getpwnam_r() from LinuxThreads again, and > > deadlocks trying to recursively lock its own mutex. Obviously, if > > there was no mutex the stack would leak out the back of my computer > > :-) > > > > Any ideas here? > > Three ideas: > > 1) Change the linuxthreads port to not implement getpwname > in the way that it is (or at all and let it use libc's > version). Probably the easiest way; just include the getpw(nam|uid)_r code in #ifndef BSD (or #ifndef __FreeBSD__ if it's only a FBSD problem). > > 2) Change libc so that getpwnam and getpwnam_r are weak > references to _getpwnam and _getpwnam_r respectively > and have the "_" versions be the real implementation. > Make all references in libc use _getpwname and > _getpwnam_r (including the call to _getpwnam_r in > _getpwnam). I think this would still cause the same problem, but not sure. > > 3) CVSup to the latest 5.x and use libthr or libkse and > forget linuxthreads. Not an option, as my app needs to be runnable on both BSD and Linux. (So LinuxThreads was a natural choice :-) Then again, if there's a pthread-compatible wrapper around libthr, I might be able to consider it... Well, I think I'll probably do 1) for future users, and 4) (switch to libpth) for now :-) -- Josh > > -- > Dan Eischen