https://bugs.linaro.org/show_bug.cgi?id=1457
--- Comment #1 from Ola Liljedahl <[email protected]> --- Read of size 4 at 0x7f2dd1849018 by thread T19: #0 odp_queue_create /home/mike/git/odp/platform/linux-generic/odp_queue.c:205 (odp_timer+0x0000000c3f5b) if (queue->s.status != QUEUE_STATUS_FREE) #1 worker_entrypoint /home/mike/git/odp/test/validation/odp_timer.c:277 (odp_timer+0x0000000baa58) Previous write of size 4 at 0x7f2dd1849018 by thread T15: #0 odp_queue_create /home/mike/git/odp/platform/linux-generic/odp_queue.c:214 (odp_timer+0x0000000c3fef) queue->s.status = QUEUE_STATUS_NOTSCHED; #1 worker_entrypoint /home/mike/git/odp/test/validation/odp_timer.c:277 (odp_timer+0x0000000baa58) If there is a data race here (read after write without any synchronization?), I believe that data race is in the queue module and not the timer module. This is the timer validation program where each worker thread creates a private queue, uses it during the test (odp_queue_deq(), the timer module calls odp_queue_enq()) and then destroys the queue (after all associated timers have been freed). There is no synchronization problem on this level. There is no indication in the ThreadSanitizer report that this is a problem with the timer *module*. I suggest that this bug report is moved to the component Queues (which does not exist!). -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
