Bug#660960: tight loop attempting to madvise(..., MADV_DONTNEED) locked memory
The madvice() busy loop will occur on all systems where page size is bigger than 4KB. From supported architectures, e.g. MIPS and SPARC suffer because of this. See e.g. http://lists.debian.org/debian-mips/2012/07/msg00043.html iceweasel is unusable on these platforms. :-( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660960: tight loop attempting to madvise(..., MADV_DONTNEED) locked memory
On Thu, Apr 26, 2012 at 08:58:24PM -0500, Bob Tracy wrote: Earlier messages in this bug-report thread indicated use of Flash would also trigger the madvise() madness. I'm happy (?) to report that visiting Flash-enabled web sites reliably triggers this condition on the Alpha platform for *all* releases of firefox/iceweasel after 9.0.1. Michael Cree gets the nod for noting his backtraces ending in madvise() while we Alpha users were trying to figure out what was going on. Mike H. -- Thanks in advance for any fix/workaround you can come up with. Let me guess... alpha has non-4K page size. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660960: tight loop attempting to madvise(..., MADV_DONTNEED) locked memory
On Fri, Apr 27, 2012 at 08:12:51AM +0200, Mike Hommey wrote: Let me guess... alpha has non-4K page size. Page size was 8K the last time I checked, which was admittedly a long time ago. --Bob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660960: tight loop attempting to madvise(..., MADV_DONTNEED) locked memory
Earlier messages in this bug-report thread indicated use of Flash would also trigger the madvise() madness. I'm happy (?) to report that visiting Flash-enabled web sites reliably triggers this condition on the Alpha platform for *all* releases of firefox/iceweasel after 9.0.1. Michael Cree gets the nod for noting his backtraces ending in madvise() while we Alpha users were trying to figure out what was going on. Mike H. -- Thanks in advance for any fix/workaround you can come up with. --Bob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660960: tight loop attempting to madvise(..., MADV_DONTNEED) locked memory
On Sat, Feb 25, 2012 at 01:07:11AM +, Jamie Heilman wrote:
Jamie Heilman wrote:
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 0x77407407 in madvise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7663169e in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so
#2 0x76628886 in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so
#3 0x76628d51 in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so
#4 0x7508d697 in nsJSContext::ScriptEvaluated
(this=0x7fffe52690a0,
aTerminated=true)
at /tmp/buildd/iceweasel-10.0.2/dom/base/nsJSEnvironment.cpp:3122
#5 0x74f02e79 in nsCxPusher::Pop (this=0x7fff8d50)
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.
OK, there was a small cleanup with
https://bugzilla.mozilla.org/show_bug.cgi?id=702681 but a deeper
refactor came with https://bugzilla.mozilla.org/show_bug.cgi?id=702251
and that new DecommitArenasFromAvailableList function looks more sane
than DecommitFreePages did, but there's still no attempt to check
errno in DecommitMemory or figure out why madvise fails, which is
somewhat inconsistent with the:
while (madvise(address, bytes, MADV_DONTNEED) == -1 errno == EAGAIN) { }
pattern used in yarr, but whatever. 702251 appeared to be fixed in
the aurora branch, so I installed 12.0~a2+20120217042010-1 to see if I
could reproduce the issue, and unfortunately I still could. On the
trunk, the jsgcchunk stuff got generalized with
https://bugzilla.mozilla.org/show_bug.cgi?id=720439 and DecommitMemory
was effectively renamed to MarkPagesUnused but is otherwise the same
as it was. So it doesn't appear like this problem is scheduled to go
away anytime soon. I wish I could get gdb to pick up on the debugging
information for libmozjs, but despite having the -dbg package
installed I just can't seem to get it to do so. (I'd welcome any tips
there.)
Try removing the /usr/lib/xulrunner-*/libmozjs.so symlink.
Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660960: tight loop attempting to madvise(..., MADV_DONTNEED) locked memory
Mike Hommey wrote: Jamie Heilman wrote: #0 0x77407407 in madvise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7663169e in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so #2 0x76628886 in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so #3 0x76628d51 in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so #4 0x7508d697 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 0x77407407 in madvise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7494d69e in js::gc::DecommitMemory (addr=optimized out, size=optimized out) at /tmp/buildd/iceweasel-10.0.2/js/src/jsgcchunk.cpp:370 #2 0x74944886 in DecommitFreePages (cx=optimized out) at /tmp/buildd/iceweasel-10.0.2/js/src/jsgc.cpp:2406 #3 SweepPhase (gckind=GC_SHRINK, gcmarker=0x7fff9460, 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 0x74944d51 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 0x75a42697 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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660960: tight loop attempting to madvise(..., MADV_DONTNEED) locked memory
On Sat, Feb 25, 2012 at 09:14:07AM +, Jamie Heilman wrote: Mike Hommey wrote: Jamie Heilman wrote: #0 0x77407407 in madvise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7663169e in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so #2 0x76628886 in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so #3 0x76628d51 in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so #4 0x7508d697 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 0x77407407 in madvise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7494d69e in js::gc::DecommitMemory (addr=optimized out, size=optimized out) at /tmp/buildd/iceweasel-10.0.2/js/src/jsgcchunk.cpp:370 #2 0x74944886 in DecommitFreePages (cx=optimized out) at /tmp/buildd/iceweasel-10.0.2/js/src/jsgc.cpp:2406 #3 SweepPhase (gckind=GC_SHRINK, gcmarker=0x7fff9460, 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 0x74944d51 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 0x75a42697 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
Bug#660960: tight loop attempting to madvise(..., MADV_DONTNEED) locked memory
Mike Hommey wrote: On Sat, Feb 25, 2012 at 09:14:07AM +, Jamie Heilman wrote: 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? A JACK client will typically mlockall(MCL_CURRENT | MCL_FUTURE) and potentially munlock some ranges belonging to common gui toolkits. This type of thing is fine when you're dealing with serious audio recording apps and you can't afford delays from page faults. Obviously it doesn't work too well with bigger applications that were never designed with that in mind. That behavior is easy to turn off, and I have, which makes ff10 usable w/the alsa jack plugin again. -- Jamie Heilman http://audible.transient.net/~jamie/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660960: tight loop attempting to madvise(..., MADV_DONTNEED) locked memory
Jamie Heilman wrote:
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 0x77407407 in madvise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7663169e in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so
#2 0x76628886 in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so
#3 0x76628d51 in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so
#4 0x7508d697 in nsJSContext::ScriptEvaluated (this=0x7fffe52690a0,
aTerminated=true)
at /tmp/buildd/iceweasel-10.0.2/dom/base/nsJSEnvironment.cpp:3122
#5 0x74f02e79 in nsCxPusher::Pop (this=0x7fff8d50)
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.
OK, there was a small cleanup with
https://bugzilla.mozilla.org/show_bug.cgi?id=702681 but a deeper
refactor came with https://bugzilla.mozilla.org/show_bug.cgi?id=702251
and that new DecommitArenasFromAvailableList function looks more sane
than DecommitFreePages did, but there's still no attempt to check
errno in DecommitMemory or figure out why madvise fails, which is
somewhat inconsistent with the:
while (madvise(address, bytes, MADV_DONTNEED) == -1 errno == EAGAIN) { }
pattern used in yarr, but whatever. 702251 appeared to be fixed in
the aurora branch, so I installed 12.0~a2+20120217042010-1 to see if I
could reproduce the issue, and unfortunately I still could. On the
trunk, the jsgcchunk stuff got generalized with
https://bugzilla.mozilla.org/show_bug.cgi?id=720439 and DecommitMemory
was effectively renamed to MarkPagesUnused but is otherwise the same
as it was. So it doesn't appear like this problem is scheduled to go
away anytime soon. I wish I could get gdb to pick up on the debugging
information for libmozjs, but despite having the -dbg package
installed I just can't seem to get it to do so. (I'd welcome any tips
there.)
--
Jamie Heilman http://audible.transient.net/~jamie/
I was in love once -- a Sinclair ZX-81. People said, No, Holly,
she's not for you. She was cheap, she was stupid and she wouldn't
load -- well, not for me, anyway. -Holly
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660960: tight loop attempting to madvise(..., MADV_DONTNEED) locked memory
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 0x77407407 in madvise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7663169e in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so
#2 0x76628886 in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so
#3 0x76628d51 in ?? () from /usr/lib/xulrunner-10.0/libmozjs.so
#4 0x7508d697 in nsJSContext::ScriptEvaluated (this=0x7fffe52690a0,
aTerminated=true)
at /tmp/buildd/iceweasel-10.0.2/dom/base/nsJSEnvironment.cpp:3122
#5 0x74f02e79 in nsCxPusher::Pop (this=0x7fff8d50)
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
