Bug#660960: tight loop attempting to madvise(..., MADV_DONTNEED) locked memory

[Jamie Heilman]

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