[pulseaudio-tickets] [Bug 77948] New: padsp: dlsym lookup on demand can lead to deadlocks

[bugzilla-daemon at freedesktop.org]

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

          Priority: medium
            Bug ID: 77948
                CC: lennart at poettering.net
          Assignee: pulseaudio-bugs at lists.freedesktop.org
           Summary: padsp: dlsym lookup on demand can lead to deadlocks
        QA Contact: pulseaudio-bugs at lists.freedesktop.org
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: fsateler at gmail.com
          Hardware: Other
            Status: NEW
           Version: unspecified
         Component: tools
           Product: PulseAudio

Forwarded from a debian bug[1].

Summary from Mike Hommey:

---
- something calls access() before jemalloc is initialized.
- access() is caught by padsp, which locks a mutex, and resolves the
original access symbol with dlsym().
- dlsym() ends up allocating memory, which triggers jemalloc
initialization code.
- jemalloc init code open()s /proc/cpuinfo.
- open() is caught by padsp, which locks a mutex before resolving the
original open symbol with dlsym().

Except that it is using the same mutex as the first time...

Really, the dlsym lookup on demand seems a bad idea, and here we hit a
really bad corner case of that implementation. Even using separate
mutexes wouldn't solve it all: imagine the original call wasn't
access(), but open(), instead.

The best thing IMHO would be to have a constructor function that does
the symbol resolution at startup.
---



[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550674

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