Package: iceweasel Version: 10.0.2-1 With the update to 10 I've been plagued by browser lockups and rabid CPU consumption. I've narrowed down how to reproduce it ... it requires a bit of setup though. First off, this is related to the way in which JACK clients lock their memory, and the use of the ALSA JACK plugin. So first, that needs to be set up, which can be done by:
1) install jackd1 package; allow the audio group rt and memlock privs 2) make sure your user is in the audio group 3) install libasound2-plugins package 4) use a .asoundrc of: pcm.jackit { type jack playback_ports { 0 system:playback_1 1 system:playback_2 } capture_ports { 0 system:capture_1 1 system:capture_2 } } pcm.!default { type plug slave.pcm "jackit" } 5) fire up a JACK server (the easiest way is to just use a network server as that way you don't even have to attach this to a real soundcard to test) with jackd -d net -a 0 -i 0 -o 2 -I 0 -O 0 6) run iceweasel; visit youtube.com and watch some mind-rot I've found this is really easy to reproduce if I use the native webm player to playback video, but harder to produce (though it still happens) if I use Flashplayer. What typically happens is that iceweasel stops responding and consumes a core's worth of CPU. An strace of the process reveals infinite and repeated calls to madvise for the same addr, same length, and always MADV_DONTNEED which is returning -1 and setting errno to EINVAL. Looking through the /proc/$pid/smaps file shows the address is the middle of a locked range. gdb backtrace of the event using the -dbg packages gave me: #0 0x00007ffff7407407 in madvise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff663169e in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so #2 0x00007ffff6628886 in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so #3 0x00007ffff6628d51 in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so #4 0x00007ffff508d697 in nsJSContext::ScriptEvaluated (this=0x7fffe52690a0, aTerminated=true) at /tmp/buildd/iceweasel-10.0.2/dom/base/nsJSEnvironment.cpp:3122 #5 0x00007ffff4f02e79 in nsCxPusher::Pop (this=0x7fffffff8d50) at /tmp/buildd/iceweasel-10.0.2/content/base/src/nsContentUtils.cpp:2694 ... Digging around, I suspect the DecommitFreePages function in js/src/jsgc.cpp ... which appears to be gone from mozilla central already, though I haven't gone and figured out what happened to it yet. Anyway, getting hung up in a tight loop calling the same function over and over again that's never going to succeed isn't cool, and didn't used to happen. So despite the somewhat unusual setup here with the locked memory and all that, I'm pretty sure this is a bug in firefox. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org