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
-- 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.