<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <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 <a class="email" href="mailto:emil.l.velikov@gmail.com" title="Emil Velikov <emil.l.velikov@gmail.com>"> Emil Velikov</a> <pre>(In reply to Rob Clark from <a href="show_bug.cgi?id=98048#c13">comment #13</a>) > (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. > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>