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

[Mike Hommey]

On Sat, Feb 25, 2012 at 09:14:07AM +0000, Jamie Heilman wrote:
> 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.

Why the hell is alsa/jack locking memory handled by the javascript
engine anyway?

Mike