[Xcb] [Bug 98048] libpthread-stubs must NOT provide symbols which depend on actual implementation

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98048

--- Comment #8 from Josh Triplett <josh at freedesktop.org> ---
(In reply to Rob Clark from comment #6)
> (In reply to Emil Velikov from comment #5)
> > libpthreads-stub must _not_ provide stub implementation for APIs that
> > absolutely requires locking/other. Would that be pthread_mutexattr_settype
> > or any other.
> 
> or pthread_mutex_lock()/unlock() for that matter ;-)
> 
> pthreads-stub should only be used where you don't actually have *any*
> threads.. so in that regard, stubbing pthread_mutexattr_settype() is
> completely legit.
> 
> The problem *sounds* like we somehow have a libc that provides *part* of the
> pthreads API, but not all, so you end up mixing stub and real
> implementation?

This, exactly.

If pthread-stubs provides all the stubs for pthread mutexes, then it makes
sense for pthread-stubs to provide a stub for pthread_mutexattr_settype, which
can always succeed at setting a mutex as recursive, because you can lock and
unlock it all you want.

However, if you actually have a real non-stub implementation of pthread
mutexes, but that implementation doesn't have pthread_mutexattr_settype,
pthread-stubs *must not* provide a stub that always succeeds, because then a
program would expect that it has successfully set a mutex as recursive, and
then deadlock.  (As well as the "uninitialized data" issue.)

Is Mesa linking against the libc6 stubs, and then running in the
single-threaded case?  Or does it somehow end up running against the real
libpthread but also calling pthread-stubs functions?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xcb/attachments/20161007/35b4d2f7/attachment.html>