<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#c8">Comment # 8</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:josh@freedesktop.org" title="Josh Triplett <josh@freedesktop.org>"> <span class="fn">Josh Triplett</span></a>
</span></b>
        <pre>(In reply to Rob Clark from <a href="show_bug.cgi?id=98048#c6">comment #6</a>)
<span class="quote">> (In reply to Emil Velikov from <a href="show_bug.cgi?id=98048#c5">comment #5</a>)
> > 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?</span >

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?</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>