Open Bug 1145866 Opened 5 years ago Updated 2 years ago

Allocation size overflow

Categories

(Core :: DOM: Workers, defect, P3)

36 Branch
x86
Windows 7
defect

Tracking

()

Tracking Status
e10s - ---

People

(Reporter: mayitosj09, Unassigned)

References

Details

(4 keywords, Whiteboard: [sg:dos])

Attachments

(2 files)

Attached file Crash.htm
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150305021524

Steps to reproduce:

To open the archive "crash.html", firefox crash after of a few minutes.
Steps:
1: Open the archive "Crash.html"
2: Wait a few minutes
3: view the result


Actual results:

Firefox has a crash, this not ocurred in old versions


Expected results:

firefox not have to be closed
Do you have a crash report ID from about:crashes ?
Flags: needinfo?(mayitosj09)
I not have sent to Mozilla the error ID, in the following days i will send and inform him about to ID
Component: Untriaged → DOM: Workers
Product: Firefox → Core
[@ libsystem_malloc.dylib@0x11256 ]
bp-82ce5125-7ba0-4ba5-9e30-2bf872150324

[@ zone_malloc ]
bp-2e691cba-d627-4230-a3b1-3b8142150324
bp-e4a82e6d-6639-437d-8316-6b7422150324

No stacks for any of them, just the crashing function. All three crash at the address 0x5f3ffff8 but I don't know what kind of magic number that might be.
I can't seem to reproduce this crash on my Windows 7 machine. I've had the testcase loaded and running for 30 minutes in four separate profiles running Firefox 39.0a1, 38.0a2, 37.0b7, and 36.0.4 in parallel. Neither of these have crashed yet. Is there some trick to get the testcase working?
QA Whiteboard: [triaged]
The ID of the report is as follows:
https://crash-stats.mozilla.com/report/index/ead6cfe4-2858-4843-a03f-5ded42150325
Flags: needinfo?(mayitosj09)
Attached image FF29 No Crash.JPG
Tested in FF 29, no crash
Your testcase references file:///localhost:9997/echo  -- is that a file we need to reproduce the issue, or is a load failure part of the test?
Flags: needinfo?(mayitosj09)
The address ''file:///localhost:9997/echo'' is part of the test,
it is not necessary to reproduce
the bug.
Flags: needinfo?(mayitosj09)
I am unable to reproduce a crash of any kind here (Win 8.1, x64 build). The browser definitely becomes unresponsive, but that's all.
Comment 6 is a safe out-of-memory crash.
Group: core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:dos]
Dan, you set this bug to NEW on April 7. Does that mean you're able to reproduce this crash?
Flags: needinfo?(dveditz)
Yes, comment 3 are the crashes I got.
Flags: needinfo?(dveditz)
(In reply to Daniel Veditz [:dveditz] from comment #13)
> Yes, comment 3 are the crashes I got.

Do you have any steps to reproduce?
On Fx29+, I can see it pegging a lot of CPU and the memory usage bouncing up and down, but no crash. However, I see the same CPU & memory usage death spiral as Anthony reported in comment 5 when trying to close Firefox.

On a current nightly build, I can reproduce the death spiral just by loading the page (no need to close Firefox first) if e10s is enabled. With e10s disabled, the behavior is the same as above.

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=12ea03a70243&tochange=1ad9af3a2ab8

Too old for automated inbound bisection, unfortunately. The below revs look possibly-relevant, though.
11f269e4597e	Ben Turner — Bug 924089 - 'Enable SharedWorker by default', r=ehsan+khuey.
499de7433a6a	Ben Turner — Bug 939196 - Allow nsThread to have nested event queues, r=bsmedberg.
072161a22749	Ben Turner — Bug 939182 - Prevent mock timers from interfering with the message pump machinery, r=bsmedberg.
fa74710fdeef	Ben Turner — Bug 939182 - Integrate the chromium MessageLoop into nsThread, r=bsmedberg.
1d2659a098c2	Ben Turner — Bug 939182 - Add 'eventWasProcessed' argument to nsIThreadObserver::afterProcessNextEvent(), r=bsmedberg.
475f1db6b910	Ben Turner — Bug 939182 - Clean up message loop code, r=bsmedberg.
ad0aca1ace4e	Ben Turner — Bug 947575 - Fix IPDL unit tests on windows, r=bsmedberg.

Kyle, is there something we can be doing better here?
Flags: needinfo?(khuey)
I pinged Kyle on IRC about this bug. He said that the root issue here may be the same as bug 1003730, so it'd be worth checking back on this if/when that gets fixed. Beyond that, the regression range just points to when SharedWorker was turned on, which is what the testcase uses and this is pointing to a simple resource exhaustion issue, so not very high priority otherwise.

He also suggested putting this up for e10s tracking given the difference in behavior w/ it enabled.

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #15)
> On a current nightly build, I can reproduce the death spiral just by loading
> the page (no need to close Firefox first) if e10s is enabled. With e10s
> disabled, the behavior is the same as above.
tracking-e10s: --- → ?
Flags: needinfo?(khuey)
See Also: → 1003730
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.