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

[Jamie Heilman]

Mike Hommey wrote:
> > Jamie Heilman wrote:
> > > #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, 
> Try removing the /usr/lib/xulrunner-*/libmozjs.so symlink.

Well, that was easy.  And yeah, that confirms my suspicions:

#0  0x00007ffff7407407 in madvise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff494d69e in js::gc::DecommitMemory (addr=<optimized out>, 
    size=<optimized out>)
    at /tmp/buildd/iceweasel-10.0.2/js/src/jsgcchunk.cpp:370
#2  0x00007ffff4944886 in DecommitFreePages (cx=<optimized out>)
    at /tmp/buildd/iceweasel-10.0.2/js/src/jsgc.cpp:2406
#3  SweepPhase (gckind=GC_SHRINK, gcmarker=0x7fffffff9460, cx=0x7fffe3b1d330)
    at /tmp/buildd/iceweasel-10.0.2/js/src/jsgc.cpp:2640
#4  MarkAndSweep (gckind=GC_SHRINK, cx=0x7fffe3b1d330)
    at /tmp/buildd/iceweasel-10.0.2/js/src/jsgc.cpp:2677
#5  GCCycle (cx=0x7fffe3b1d330, comp=<optimized out>, gckind=GC_SHRINK)
    at /tmp/buildd/iceweasel-10.0.2/js/src/jsgc.cpp:2921
#6  0x00007ffff4944d51 in js_GC (cx=0x7fffe3b1d330, comp=0x0, 
    gckind=GC_SHRINK, reason=js::gcstats::MAYBEGC)
    at /tmp/buildd/iceweasel-10.0.2/js/src/jsgc.cpp:2983
#7  0x00007ffff5a42697 in nsJSContext::ScriptEvaluated (this=0x7fffe3c954c0, 
    aTerminated=true)
    at /tmp/buildd/iceweasel-10.0.2/dom/base/nsJSEnvironment.cpp:3122

So yeah, not checking errno and repeatedly attempting to MADV_DONTNEED
a range of memory that fails with a reason that isn't EAGAIN ... won't
wash.  While the whole alsa/jack plugin thing is somewhat unusal, that
really is just an easy way to showcase the bigger problem of the lazy
approach to madvise that firefox is taking.  I can reconfigure my
audio setup to avoid locking memory easily enough.  Still, firefox
shoudln't re-madvise memory ranges doomed to failure over and over
again.

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/