https://bugs.freedesktop.org/show_bug.cgi?id=77948
Priority: medium
Bug ID: 77948
CC: [email protected]
Assignee: [email protected]
Summary: padsp: dlsym lookup on demand can lead to deadlocks
QA Contact: [email protected]
Severity: normal
Classification: Unclassified
OS: All
Reporter: [email protected]
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.
_______________________________________________
pulseaudio-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs
