Bug#550674: iceweasel hangs when used with padsp
Mike Hommey
mh at glandium.org
Thu Dec 24 13:52:23 UTC 2009
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
More information about the pkg-mozilla-maintainers
mailing list