crash [OOM | small] in js::gc::ArenaLists::forceFinalizeNow(js::FreeOp*, js::gc::AllocKind) (Reason: EXCEPTION_BREAKPOINT)

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: marvinhk, Unassigned)

Tracking

({crash})

35 Branch
x86_64
Windows 7
crash
Points:
---

Firefox Tracking Flags

(firefox47 affected, firefox48 affected, firefox49 affected, firefox-esr45 affected, firefox50 affected)

Details

(crash signature)

Attachments

(3 attachments)

273.39 KB, application/x-gzip
Details
329.80 KB, application/x-gzip
Details
1.09 MB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
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…
Keywords: crash

Comment 1

4 years ago
Is it a way to reproduce the crash more fastly, like every minute? Waiting for a few hours is too long to test...
(Reporter)

Comment 2

4 years ago
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.

Updated

4 years ago
Duplicate of this bug: 1111681

Updated

4 years ago
Duplicate of this bug: 1113956

Updated

4 years ago
Duplicate of this bug: 1115050

Updated

4 years ago
Duplicate of this bug: 1115521

Updated

4 years ago
Duplicate of this bug: 1115540

Comment 8

4 years ago
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.
(Reporter)

Comment 10

4 years ago
(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.)
(Reporter)

Comment 13

4 years ago
Created attachment 8543991 [details]
anonymized memory report (20150105A)

anonymized memory report before the periodic reload
(Reporter)

Comment 14

4 years ago
Created attachment 8543993 [details]
anonymized report (20150105B)

anonymized memory report after the periodic reload
(Reporter)

Comment 15

4 years ago
Created attachment 8543995 [details]
memory report diff (20150105)

screens of report diff on standard memory reports for reference
(Reporter)

Comment 16

4 years ago
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 ...

Comment 17

4 years ago
i have the same problem its frustrating
See Also: → bug 1089682

Comment 18

4 years ago
I have the same problem with Firefox 35.0. They really need to work on stability. Firefox is more and more instable.
there have been other facebook+memory bug reports.
one example is bug 1116992

Updated

3 years ago
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?
Flags: needinfo?(marvinhk)
Whiteboard: [closeme 2016-08-01]
(Reporter)

Comment 23

3 years ago
on 48.0b3 now and do not experience this crash, feel free to close if bug not further actionable
Flags: needinfo?(marvinhk)

Updated

3 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME

Updated

3 years ago
Whiteboard: [closeme 2016-08-01]
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.