Bug 971350

Eventually X doesn't check if pthread_barrier_init succeeds and passes it
a zero count (upon which it exits with barrier uninitialized and thus likely
all zeros).

Any idea why this doesn't happen with gcc < 6?

No idea yet - trying to create a Test-DVD with gdb and required debuginfo/source
packages to look what happens.

But certainly in ./src/gallium/auxiliary/os/os_thread.h

typedef pthread_barrier_t pipe_barrier;

static inline void pipe_barrier_init(pipe_barrier *barrier, unsigned count)
{
   pthread_barrier_init(barrier, NULL, count);
}

static inline void pipe_barrier_destroy(pipe_barrier *barrier)
{
   pthread_barrier_destroy(barrier);
}

static inline void pipe_barrier_wait(pipe_barrier *barrier)
{
   pthread_barrier_wait(barrier);
}

doesn't properly verify pthread_barrier_init succeeds (nor does it return
the return value).

in ./src/gallium/drivers/llvmpipe/lp_rast.c I see

   for (i = 0; i < MAX2(1, num_threads); i++) {
      struct lp_rasterizer_task *task = &rast->tasks[i];
...
   rast->num_threads = num_threads;

   rast->no_rast = debug_get_bool_option("LP_NO_RAST", FALSE);

   create_rast_threads(rast);

   /* for synchronizing rasterization threads */
   pipe_barrier_init( &rast->barrier, rast->num_threads );

so the loop cares for num_threads < 1 which looks to me it can be zero
and this value is passed to pipe_barrier_init unmodified.

Looks like a non-GCC specific issue (I didn't try to see if it reproduces
with GCC 5).  Note that I have a new LLVM in Staging:Gcc6 as well (not
sure if that matters).

Caller has

   screen->num_threads = util_cpu_caps.nr_cpus > 1 ? util_cpu_caps.nr_cpus : 0;
#ifdef PIPE_SUBSYSTEM_EMBEDDED
   screen->num_threads = 0;
#endif
   screen->num_threads = debug_get_num_option("LP_NUM_THREADS", screen->num_threads);
   screen->num_threads = MIN2(screen->num_threads, LP_MAX_THREADS);

   screen->rast = lp_rast_create(screen->num_threads);

so there are certainly cases where num_threads == 0.  I suppose in that
case the pipe_barrier should be not used at all?  In fact if nr_cpus is 1
(as default in qemu) num_threads will be zero.

Hmm, running X in gdb just hangs the machine :/

Ok, probably "caused" by the new glibc as b02840ba introduced the modulo operation.

commit b02840bacdefde318d2ad2f920e50785b9b25d69
Author: Torvald Riegel <triegel@redhat.com>
Date:   Wed Jun 24 14:37:32 2015 +0200

    New pthread_barrier algorithm to fulfill barrier destruction requirements.
    
    The previous barrier implementation did not fulfill the POSIX requirements
    for when a barrier can be destroyed.  Specifically, it was possible that
    threads that haven't noticed yet that their round is complete still access
    the barrier's memory, and that those accesses can happen after the barrier
    has been legally destroyed.
    The new algorithm does not have this issue, and it avoids using a lock
    internally.


You need to fix Mesa to not call pthread_barrier_init with zero count
(or not destroy or wait on such barrier).  You likely don't wait on it
already as that has the same modulo operation.

Guard in ./src/gallium/drivers/llvmpipe/lp_rast.c

void lp_rast_destroy( struct lp_rasterizer *rast )
{
...
  /* for synchronizing rasterization threads */
   pipe_barrier_destroy( &rast->barrier );


with if rast->num_threads >= 1

the pipe_thread_wait in this function is already guarded by means of the loop

   for (i = 0; i < rast->num_threads; i++) {
#ifdef _WIN32
      pipe_semaphore_wait(&rast->tasks[i].work_done);
#else
      pipe_thread_wait(rast->threads[i]);
#endif
   }

Oh, and best not call pipe_barrier_init with num-threads == 0 either.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=4ed4c1d9210b11ce6faea81455c21531904ea45b

And X indeed works fine with qemu -smp cpus=2 ...

Talked to Richard. I'll add the patch to Mesa in X11:XOrg and submit it to factory/TW.

(In reply to Stefan Dirsch from comment #9)
> Talked to Richard. I'll add the patch to Mesa in X11:XOrg and submit it to
> factory/TW.

done (SR#373686)

Richard, feel free to linkpac to obs://X11:XOrg/Mesa for now. ;-)

This is an autogenerated message for OBS integration:
This bug (971350) was mentioned in
https://build.opensuse.org/request/show/373686 Factory / Mesa

This is an autogenerated message for OBS integration:
This bug (971350) was mentioned in
https://build.opensuse.org/request/show/373998 Factory / Mesa