[pulseaudio-tickets] [Bug 99667] New: data race in pa_queue_pop/pa_queue_push reported by TSan

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99667

            Bug ID: 99667
           Summary: data race in pa_queue_pop/pa_queue_push reported by
                    TSan
           Product: PulseAudio
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: core
          Assignee: pulseaudio-bugs at lists.freedesktop.org
          Reporter: fabrice at bellet.info
        QA Contact: pulseaudio-bugs at lists.freedesktop.org
                CC: lennart at poettering.net

Created attachment 129321
  --> https://bugs.freedesktop.org/attachment.cgi?id=129321&action=edit
ThreadSanitizer: data race pulsecore/queue.c:98 in pa_queue_pop

This output from ThreadSanitizer suggests a data race with the glib mainloop.

The application is empathy. A pa_glib_mainloop is created in the main thread to
monitor the status of the microphone in the user interface, and a gstreamer
pipeline is constructed and running. This pipeline contains a pulsesrc element,
with its own pa_threaded_mainloop.

The problem, as I understand the output of the sanitizer, is that some events
concerning the pa_glib_mainloop are pushed by the pulsesrc thread, and pulled
by the main thread, without common locking, causing this possible race.

The first mutex owned by the pulsesrc thread concerns a GstPad, and the second
mutex is related to its pa_threaded_mainloop.

Can this race really happen, or should it be considered as a false positive ?
Where is locking missing ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20170203/eaaa464f/attachment.html>