Control: tags -1 + upstream ... but I'm not sure.
Basically, it appears that there's a race between setting a value in the main thread and reading it in another thread. The value is darktable.control->thread_res[threadid]. It's accessed in the created thread in dt_control_get_threadid_res and is set in the main thread by pthread_create() via the pthread_t* argument. I boiled the problem down to the following program, which succeeds invariably on Debian GNU/Linux amd64 but fails with regularity on Debian GNU/kfreebsd amd64: #include <pthread.h> #include <assert.h> #include <stdint.h> #include <stdio.h> pthread_t th; void *asserter(void* unused) { pthread_t self = pthread_self(), th_=th; printf("th=%jd self=%jd\n", (intmax_t)th_, (intmax_t)self); assert(pthread_equal(th_, self)); } int main() { int i; for(i=0; i<1000; i++) { pthread_create(&th, NULL, asserter, NULL); pthread_join(th, NULL); } return 0; } this is analagous to what darktable is doing in control.c: /// like asserter() 770 while(!pthread_equal(darktable.control->thread_res[threadid],pthread_self()) && threadid < DT_CTL_WORKER_RESERVED-1) 771 threadid++; 772 assert(pthread_equal(darktable.control->thread_res[threadid], pthread_self())); /// like main() 361 pthread_create(&s->thread_res[k], NULL, dt_control_work_res, s); however, because more takes place in the child thread between dt_control_work_res and the access of darktable.control->thread_res[threadid] the failure is less frequent in darktable than in my sample program. Because the specification of pthread_create does not explicltly say that the assignment to its 'pthread_t *thread' output parameter occurs before the thread's start_routine is called, I believe darktable is asking from pthreads something it has no right to expect. Jeff -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org