[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 #15 from Emil Velikov <emil.l.velikov at gmail.com> ---
(In reply to Rob Clark from comment #13)
> (In reply to Emil Velikov from comment #11)
> > (In reply to Rob Clark from comment #6)
> > > so in that regard, stubbing pthread_mutexattr_settype() is
> > > completely legit.
> > > 
> > Not really :-\ AFAICT setting/changing the mutexattr implies that one
> > requires actual locking.
> 
> Well, to be super-anal, pthreads-stub should perhaps flag an error or assert
> or something for non-recursive mutex if recursively acquired.  But I guess
> no one has cared about that so far.  It doesn't help that the default mutex
> type can be (but doesn't have to be) recursive.
> 
> But I don't see how setting mutexattr implies that you require locking in a
> single-threaded environment any more than pthread_mutex_lock() does.  So I
> still think stubbing the mutexattr fxns is not wrong..  but I guess there is
> an unfortunate interaction with how pthread syms that aren't in libc get
> resolved?  Maybe reverting the stubs is more convenient than fixing glibc if
> we can't figure out how to get the symbols from libpthread before
> pthread-stubs.
> 
Yes, we can add a lot more error checking/alike and make things more robust. By
then they won't be plain stubs though ;-)

If we consider that mesa (and maybe others) do zero error checking for
pthread_mutexattr_* and pthread_mutex_init and others, it smells like accident
waiting to happen. Guess we should fix that, one of these days as well.

> That said, all I have of pthreads-stubs in my filesystem is the .pc file,
> which I guess explains why I am not seeing this issue?
Pretty much. If you/Ben rebuild pthreads-stubs (and packages which depend on
it) you'll see issues similar to the ones Ian reported.

-- 
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/20161010/01afb6be/attachment.html>