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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org