Bug#550674: iceweasel hangs when used with padsp

[Mike Hommey]

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