Open Bug 1145866 Opened 5 years ago Updated 2 years ago
Allocation size overflow
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 ?
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?
Not sure if these are related but after giving up on the test I closed all the browser windows and got some shutdownhang crashes: https://crash-stats.mozilla.com/report/index/2467e46c-12b2-49d9-85d9-111e52150325 https://crash-stats.mozilla.com/report/index/6f8e7bae-cc86-4ab4-8e67-136842150325 https://crash-stats.mozilla.com/report/index/58d11e6f-2461-47ee-94bb-f124e2150325
The ID of the report is as follows: https://crash-stats.mozilla.com/report/index/ead6cfe4-2858-4843-a03f-5ded42150325
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?
The address ''file:///localhost:9997/echo'' is part of the test, it is not necessary to reproduce the bug.
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.
Dan, you set this bug to NEW on April 7. Does that mean you're able to reproduce this crash?
Yes, comment 3 are the crashes I got.
(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?
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.
You need to log in before you can comment on or make changes to this bug.