Repeated location.reload() makes the "slow script" dialog ineffective (and starves GC/CC?)
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: bsterne, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash, reproducible, testcase, Whiteboard: [sg:dos][oom])
Attachments
(1 file)
121 bytes,
text/html
|
Details |
This was reported to security@m.o today by Dimitris Vlachos. Keeping this security sensitive for now because the stack looks pretty strange: bp-287b313e-6fdc-452a-b3d9-688062110311 Firefox 3.6 I couldn't get trunk to crash. I did get a bunch of these before the crash: firefox-bin(1360,0xfcf81000) malloc: *** mmap(size=16777216) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug ----- Re: The easiest way to crash firefox... This is how (JS script): ================ while(1) window.location.reload(); ================ Which keeps FF busy without beeing able to even stop the script.Also the browser keeps allocating ram until the system 'explode'. Just try the attached demo and see it running.... -----
Comment 2•13 years ago
|
||
mats: any ideas?
Comment 3•13 years ago
|
||
Firefox 1.9.2 (32 and 64-bit) debug Linux Firefox mozilla-central (32 and 64-bit) debug Linux Firefox 1.9.2 32-bit debug OSX 10.5.8 Firefox mozilla-central 32-bit debug OSX 10.5.8 Firefox 1.9.2 32-bit debug Windows XP All the above builds results in intentional OOM abort for me. I do get a "slow script" dialog on all platforms with a clean profile but it seems ineffective (the location.reload continues in the background replacing the page with the script that is to be stopped?) I don't think the OOM is due to a leak, just that GC/CC is starved from running. Firefox mozilla-central 32-bit debug Windows XP Unable to crash that one - after a while the allocated memory reported by Task Manager dropped down significantly so I assume GC/CC eventually kicked in somehow and reclaimed the memory.
Comment 4•13 years ago
|
||
(In reply to comment #0) The stack in bp-287b313e-6fdc-452a-b3d9-688062110311 looks normal to me. Why do you find it strange? > malloc: *** mmap(size=16777216) failed I did catch this in a debugger, in malloc_error_break. It's an allocation of a 22 byte string, everything in our code looks fine. I think the reason for the huge mmap size is that system malloc allocates chunks of memory for the process to avoid system calls, memory fragmentation etc. 16777216 == 0x1000000 which seems logical with such allocation schemes. AFAICT, the value is not a result of an integer overflow or otherwise bogus value.
Comment 5•12 years ago
|
||
(Josh asked me to comment if we can make this bug public.) A safe out-of-memory abort is neither a bug nor security sensitive, but comment 3 mentions that the "slow script" dialog doesn't help stopping the script so that makes it still sg:dos. I think we should keep this bug closed until that part is fixed (maybe it already is, I haven't tested).
Comment 6•12 years ago
|
||
Not sure which component owns the "slow script" feature.
Updated•12 years ago
|
Comment 7•12 years ago
|
||
(In reply to Mats Palmgren [:mats] (on vacation) from comment #6) > Not sure which component owns the "slow script" feature. DOM iirc
Assignee | ||
Updated•5 years ago
|
Comment 9•4 years ago
|
||
I think the problem here is, that the above script is an exponential call?
Today I programmed a loop like this (which is, in fact very similar to the example):
while (true) {
var foo = [];
for (var bar = 0; bar < 100; bar++) {
// Allocate some memory --> Makes the effect faster
foo[bar] = Math.random();
}
// Use something from the calculated (will it be optimized away otherwise?)
foo = (foo[Math.floor(Math.random() * Math.floor(99))]);
// Now do a reload
window.location.reload();
// Program is executed after the reload --> exponential
alert("Hello World!");
}
In my opinion, the execution of the programm should stop after the reload(). But it does not (the "alert(..)" will trigger), so for me is not clear when which of the scripts is running (the reloading should IMHO stop the old script completely and create a new instance, so the alert will never trigger).
I cannot reproduce it for now, but not only the "Stop" button was unusable, also closing the tab didn't stop the allocation of new memory. Only killing firefox does help (but if you wait long enough, your OS will do that for you).
Updated•2 years ago
|
Comment 10•2 years ago
|
||
(In reply to Thomas Pfister from comment #9)
In my opinion, the execution of the programm should stop after the reload(). But it does not (the "alert(..)" will trigger), so for me is not clear when which of the scripts is running (the reloading should IMHO stop the old script completely and create a new instance, so the alert will never trigger).
location.reload()
is asynchronous, so it isn't meant to immediately stop execution of the calling script. Navigation attempts while there is a nested event loop for a modal dialog are a bit of an ugly corner case. I'll look into what happens here, though I'm not sure it's really the same as the originally reported bug.
Updated•1 year ago
|
Description
•