User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20141222200458 Steps to reproduce: login gmail and facebook auto refresh page every 5 mins with reloadevery leave the browser ideal for a few hours Actual results: crash [OOM | small] in js::gc::ArenaLists::forceFinalizeNow(js::FreeOp*, js::gc::AllocKind) (Reason: EXCEPTION_BREAKPOINT) bug report: bp-346f541c-4bb9-4a28-a789-950552141228.
Crash Signature: [@ OOM | small ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity(unsigned int, unsigned int) | XPCWrappedNative::FlatJSObjectF…
Is it a way to reproduce the crash more fastly, like every minute? Waiting for a few hours is too long to test...
i think it depends on memory consumption (or rate of leak) - perhaps open and refresh more tabs can help. setting the refresh frequency to 10 sec and ff crashed in around an hour.
It doesn't make sense to attribute OOM|small to any function, that's why it has a generic signature for all of those in the first place. It means that we had so little memory available that we ran Out Of Memory (OOM) with a small allocation of <256KB. There's nothing specific to what's at the top of the stack. If you have reliable (!) step to reproduce OOM|small crashes, we are very interested in those, though. The steps to reproduce are the only interesting thing here, esp. if they work reliably. I'm not sure if we send a memory reports with those crashes right now, but that would also be helpful so we can find out what fills up all the memory.
What page are you auto refreshing? Do you have this problem in safe mode? You can try looking at about:memory when you are close to crashing, but not actually crashed yet, to try to figure out where the memory is going.
(In reply to Andrew McCreight [:mccr8] from comment #9) > What page are you auto refreshing? Do you have this problem in safe mode? auto refreshing on facebook pages (news feed and page feed) i think addons are disabled in safe mode ... > You can try looking at about:memory when you are close to crashing, but not > actually crashed yet, to try to figure out where the memory is going. is there anything that i should pay attention to in about:memory? i am trying to figure out the tool and obtain some diff results. I have been using latest betas and doing auto refresh for long time, there was no OOM crashes until i update to 35 betas.
> is there anything that i should pay attention to in about:memory? Just any measurements that are really big, e.g. many 100s of MBs or 1000s of MBs. They'll likely show up near the top of the "Explicit Allocations" section. You might also see large measurements at the bottom of the "Other Measurements" section. If you're unsure, you can use the "Measure and save..." button to save all the measurements and attach them to this bug, but note that if you do that it will mention all the tabs you've got open. (You can check the "anonymize" box to avoid this but that will make it harder for us to understand what's going on.)
And https://developer.mozilla.org/en-US/docs/Mozilla/Performance/about:memory has some more documentation that might be helpful.
Created attachment 8543991 [details] anonymized memory report (20150105A) anonymized memory report before the periodic reload
Created attachment 8543993 [details] anonymized report (20150105B) anonymized memory report after the periodic reload
Created attachment 8543995 [details] memory report diff (20150105) screens of report diff on standard memory reports for reference
not sure if these attachments will be helpful. it seems the problem is specific to facebook pages. but even the page content keeps changing, i wonder why there is cumulative growth of memory consumption after page reload ... i can provide more specific information if required since i am hitting this OOM crash on daily basis ...
i have the same problem its frustrating
I have the same problem with Firefox 35.0. They really need to work on stability. Firefox is more and more instable.
bp-261f11ea-364d-4b08-bc20-0de182150126 26-01-2015 16:24 bp-438b99e7-efd1-4090-bf5d-9fcc82150126 26-01-2015 15:05 bp-1ef5ea40-fff3-4048-945c-243e22150126 26-01-2015 13:58 bp-a680251d-9f0a-49d7-ac21-878e62150126 26-01-2015 13:10 bp-7665cf01-5145-4dba-8840-bf2c32150126 26-01-2015 12:38 bp-18c0e756-8011-4324-849b-3b8292150126 26-01-2015 06:28 03862528-02a2-4ddb-b931-64bbd20631f6 22-01-2015 21:59 bp-3c9aa736-f2c9-4ee4-a0d1-1b4372150123 22-01-2015 21:21 bp-605f8f91-825a-47fc-a29d-7e5f02150123 22-01-2015 19:39 bp-d87340c2-c122-4063-bce9-912312150123 22-01-2015 19:16
there have been other facebook+memory bug reports. one example is bug 1116992
Crash Signature: [@ OOM | small ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity(unsigned int, unsigned int) | XPCWrappedNative::FlatJSObjectF… → [@ OOM | small ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity(unsigned int, unsigned int) | XPCWrappedNative::FlatJSObjectF…
marvinhk are you still crashing when using a current version?
Whiteboard: [closeme 2016-08-01]
on 48.0b3 now and do not experience this crash, feel free to close if bug not further actionable
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
Crash volume for signature 'OOM | small': - nightly (50): 513 - aurora (49): 3382 - beta (48): 57158 - release (47): 204583 - esr (45): 39756 Affected platforms: Windows, Mac OS X, Linux
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox-esr45: --- → affected
You need to log in before you can comment on or make changes to this bug.