Bug 77948 - padsp: dlsym lookup on demand can lead to deadlocks
Summary: padsp: dlsym lookup on demand can lead to deadlocks
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: tools (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
Depends on:
Reported: 2014-04-25 22:06 UTC by Felipe Sateler
Modified: 2018-07-30 10:30 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Felipe Sateler 2014-04-25 22:06:18 UTC
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
Comment 1 GitLab Migration User 2018-07-30 10:30:07 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/467.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.