getpwnam + getpwnam_r + LinuxThreads port = deadlock

[Joshua Oreman]

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