Bug 77948

Summary:	padsp: dlsym lookup on demand can lead to deadlocks
Product:	PulseAudio	Reporter:	Felipe Sateler <fsateler>
Component:	tools	Assignee:	pulseaudio-bugs
Status:	RESOLVED MOVED	QA Contact:	pulseaudio-bugs
Severity:	normal
Priority:	medium	CC:	lennart
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
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.