Dummy pthread functions in libc considered harmful

[Zack Weinberg]

On Mon, Aug 24, 2015 at 2:42 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 24 Aug 2015 18:26, Samuel Thibault wrote:
>> Rich Felker, le Mon 24 Aug 2015 12:22:50 -0400, a écrit :
>> > On Mon, Aug 24, 2015 at 05:38:16PM +0200, Samuel Thibault wrote:
>> > > Andreas Schwab, le Mon 24 Aug 2015 17:30:40 +0200, a écrit :
>> > > > BZ #18853 shows how the use of the dummy pthread functions in libc can
>> > > > be harmful if dlopen brings in libpthread by dependency.
>> > >
>> > > I have to admit I've always wondered about this case, and never took
>> > > the time to report the issue, partly because I guessed people wouldn't
>> > > dlopen() while "owning" a mutex.  This can be fixed by making the mutex
>> > > stubs really modify the mutex, possibly optimized into just not using
>> > > lock prefixes etc.
>> > >
>> > > Not having proper stubs in libc makes applications write their own stubs
>> > > (see libpthread-stubs in freedesktop for instance), which will suffer
>> > > from the same issue.
>> >
>> > I agree that removing them would be a bad idea, but why not just put
>> > the actual code (real locking) in the ones in libc.so?
>>
>> That would be simpler, yes.

I have a dim memory of tripping over a situation where a program that
didn't use threads itself dlopen-ed a library that did, in the middle
of its runtime, and catastrophe ensued because some lock (probably the
malloc arena lock, but it's been a very long time) suddenly needed to
*not* be stubbed out.

Which is to say that I endorse Rich's suggestion of making the libc
versions of these functions not be dummies.

zw