641105 - Repeated location.reload() makes the "slow script" dialog ineffective (and starves GC/CC?)

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Brandon Sterne (:bsterne)]

Attachment: testcase (crashes 1.9.2)

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

[Daniel Veditz [:dveditz]]

mats: any ideas?

Comment 3

[Mats Palmgren (inactive)]

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

[Mats Palmgren (inactive)]

(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

[Mats Palmgren (inactive)]

(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

[Mats Palmgren (inactive)]

Not sure which component owns the "slow script" feature.

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to Mats Palmgren [:mats] (on vacation) from comment #6)
> Not sure which component owns the "slow script" feature.

DOM iirc

Comment 9

[Thomas Pfister]

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).

Comment 10

[Kris Maglione [:kmag]]

(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.