http://bugzilla.novell.com/show_bug.cgi?id=971350
http://bugzilla.novell.com/show_bug.cgi?id=971350#c5
--- Comment #5 from Richard Biener ---
Ok, probably "caused" by the new glibc as b02840ba introduced the modulo
operation.
commit b02840bacdefde318d2ad2f920e50785b9b25d69
Author: Torvald Riegel
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
}
--
You are receiving this mail because:
You are on the CC list for the bug.
