reassign 550674 pulseaudio-utils affects 550674 iceweasel iceape severity 550674 important thanks
On Thu, Dec 24, 2009 at 08:14:09AM -0500, Nathan A. Stine wrote: > On Thu, 2009-12-24 at 09:16 +0100, Mike Hommey wrote: > > On Wed, Dec 23, 2009 at 07:36:37PM -0500, Nathan A. Stine wrote: > > > #0 __lll_lock_wait () > > > at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 > > > #1 0x00007f54753a1e79 in _L_lock_949 () from /lib/libpthread.so.0 > > > #2 0x00007f54753a1c9b in __pthread_mutex_lock (mutex=0x7f5475cd3680) > > > at pthread_mutex_lock.c:61 > > > #3 0x00007f5475acc1a0 in padsp_disabled () at utils/padsp.c:300 > > > #4 0x00007f5475acfe85 in dsp_cloak_enable (filename=0x411609 > > > "/proc/cpuinfo", > > > flags=0, mode=0) at utils/padsp.c:314 > > > #5 real_open (filename=0x411609 "/proc/cpuinfo", flags=0, mode=0) > > > at utils/padsp.c:1461 > > > #6 0x00007f5475ad0b49 in open (filename=0x7f5475cd3680 "\002", > > > flags=128) > > > at utils/padsp.c:1494 > > > #7 0x000000000040cd84 in malloc_ncpus () at jemalloc.c:5316 > > > #8 malloc_init_hard () at jemalloc.c:5625 > > > #9 0x000000000040e525 in malloc_init (num=1, size=32) at > > > jemalloc.c:5567 > > > #10 calloc (num=1, size=32) at jemalloc.c:6321 > > > #11 0x00007f54758c6360 in _dlerror_run (operate=0x7f54758c60b0 > > > <dlsym_doit>, > > > args=0x7fff0f3eb940) at dlerror.c:142 > > > #12 0x00007f54758c607a in __dlsym (handle=<value optimized out>, > > > name=<value optimized out>) at dlsym.c:71 > > > #13 0x00007f5475acc313 in dlsym_fn (pathname=<value optimized out>, > > > mode=4) > > > at utils/padsp.c:141 > > > #14 access (pathname=<value optimized out>, mode=4) at > > > utils/padsp.c:2395 > > > #15 0x0000000000402042 in FolderExists (argc=1, argv=0x7fff0f3efc48) > > > at nsXULStub.cpp:151 > > > #16 main (argc=1, argv=0x7fff0f3efc48) at nsXULStub.cpp:330 > > > > > > Looks like something in libc6 is what's waiting. Let me know if you > > > need anything else. > > > > Thanks. > > > > Would you have the trace for other threads ? It looks similar to a case > > we had with aoss, libtrash and others, but not quite. > > > > Mike > > Mike, > > Looks like there are no other threads. Attached is my results when > running thread apply all bt full. Thanks, The original thread dump was enough, actually, if I had cared reading pulseaudio code. Here is what happens: - something in nsXULStub 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. Mike -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
