Closed Bug 1115929 Opened 10 years ago Closed 8 years ago

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

Categories

(Core :: JavaScript: GC, defect)

Product:
Core
Component:
JavaScript: GC
Version:
35 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox47 --- affected
firefox48 --- affected
firefox49 --- affected
firefox-esr45 --- affected
firefox50 --- affected

People

(Reporter: marvinhk, Unassigned)

References

Details

(Keywords: crash)

Crash Data

Attachments

(3 files)

anonymized memory report (20150105A)
273.39 KB, application/x-gzip
Details
anonymized report (20150105B)
329.80 KB, application/x-gzip
Details
memory report diff (20150105)
1.09 MB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details 
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…
Keywords: crash
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.)
anonymized memory report before the periodic reload
anonymized memory report after the periodic reload
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
See Also: → 1089682
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
Crash Signature: , unsigned int) | XPCWrappedNative::FlatJSObjectFinalized() | js_ReportUncaughtException(JSContext*) | js::gc::ArenaLists::forceFinalizeNow(js::FreeOp*, js::gc::AllocKind) | js::gc::ArenaLists::queueObjectsForSweep(js::FreeOp*) ] → , unsigned int) | XPCWrappedNative::FlatJSObjectFinalized() | js_ReportUncaughtException(JSContext*) | js::gc::ArenaLists::forceFinalizeNow(js::FreeOp*, js::gc::AllocKind) | js::gc::ArenaLists::queueObjectsForSweep(js::FreeOp*) ] [@ mozalloc_abort | moza…
marvinhk
are you still crashing when using a current version?
Flags: needinfo?(marvinhk)
Whiteboard: [closeme 2016-08-01]
on 48.0b3 now and do not experience this crash, feel free to close if bug not further actionable
Flags: needinfo?(marvinhk)
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
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.

Attachment

General

Creator:
Created:
Updated:
Size: