<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - libpthread-stubs must NOT provide symbols which depend on actual implementation"
href="https://bugs.freedesktop.org/show_bug.cgi?id=98048#c15">Comment # 15</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - libpthread-stubs must NOT provide symbols which depend on actual implementation"
href="https://bugs.freedesktop.org/show_bug.cgi?id=98048">bug 98048</a>
from <span class="vcard"><a class="email" href="mailto:emil.l.velikov@gmail.com" title="Emil Velikov <emil.l.velikov@gmail.com>"> <span class="fn">Emil Velikov</span></a>
</span></b>
<pre>(In reply to Rob Clark from <a href="show_bug.cgi?id=98048#c13">comment #13</a>)
<span class="quote">> (In reply to Emil Velikov from <a href="show_bug.cgi?id=98048#c11">comment #11</a>)
> > (In reply to Rob Clark from <a href="show_bug.cgi?id=98048#c6">comment #6</a>)
> > > 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.
> </span >
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.
<span class="quote">> 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?</span >
Pretty much. If you/Ben rebuild pthreads-stubs (and packages which depend on
it) you'll see issues similar to the ones Ian reported.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>