Closed
Bug 605752
Opened 14 years ago
Closed 14 years ago
crash [@ JSC::ExecutablePool::ExecutablePool(unsigned int) ]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta8+ |
People
(Reporter: scoobidiver, Assigned: dmandelin)
References
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
9.79 KB,
patch
|
dvander
:
review+
|
Details | Diff | Splinter Review |
Build: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101019 Firefox/4.0b8pre It is a residual crash signature that exists in trunk builds. It is #95 top crasher in 4.0b8pre for the last week. Signature JSC::ExecutablePool::ExecutablePool(unsigned int) UUID 3c67e473-62d7-4ed5-9970-59c852101019 Time 2010-10-19 19:23:43.179985 Uptime 13751 Last Crash 76767 seconds (21.3 hours) before submission Install Age 14980 seconds (4.2 hours) since version was first installed. Product Firefox Version 4.0b8pre Build ID 20101019041714 Branch 2.0 OS Windows NT OS Version 6.1.7600 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 11 Crash Reason EXCEPTION_ACCESS_VIOLATION_WRITE Crash Address 0xffffffffbbadbeef App Notes AdapterVendorID: 10de, AdapterDeviceID: 0611 Frame Module Signature [Expand] Source 0 mozjs.dll JSC::ExecutablePool::ExecutablePool js/src/assembler/jit/ExecutableAllocator.h:336 1 mozjs.dll JSC::ExecutableAllocator::poolForSize js/src/assembler/jit/ExecutableAllocator.h:205 2 mozjs.dll js::mjit::Compiler::finishThisUp js/src/methodjit/Compiler.cpp:347 3 mozjs.dll js::mjit::Compiler::performCompilation js/src/methodjit/Compiler.cpp:195 4 mozjs.dll js::mjit::TryCompile js/src/methodjit/Compiler.cpp:222 5 mozjs.dll js::RunScript js/src/jsinterp.cpp:630 6 mozjs.dll js::Execute js/src/jsinterp.cpp:998 7 mozjs.dll JS_EvaluateUCScriptForPrincipals js/src/jsapi.cpp:4882 8 mozjs.dll JS_EvaluateUCScriptForPrincipalsVersion js/src/jsapi.cpp:4858 9 xul.dll nsJSContext::EvaluateString dom/base/nsJSEnvironment.cpp:1702 More reports at: http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=JSC%3A%3AExecutablePool%3A%3AExecutablePool%28unsigned%20int%29
I'm hitting this all over the place: * http://crash-stats.mozilla.com/report/index/bp-616a9b73-ab19-4fa3-b4e7-1b47a2101108 * http://crash-stats.mozilla.com/report/index/bp-e907cbc6-414b-4e49-b19a-7c4492101112 I have no extensions installed at all. I am running 32bit Minefield nightlies on Win7 64bit. It doesn't seem to be related to anything I'm doing. Sometimes Firefox is simply sitting there in the background when it crashes. I have a copious amount of tabs open, probably about a 100, two app-tabs that are self updating, namely zimbra & tbpl. 90% of my open tabs are bugzilla pages, so there's nothing too exceptional about them. I'm not using tabcandy for anything either. Hope that helps.
Sounds like this needs to block, maybe even b8.
blocking2.0: --- → ?
This is an out-of-memory crash. What does your browser's heap usage look like?
Assignee | ||
Updated•14 years ago
|
Assignee: general → dmandelin
blocking2.0: ? → beta8+
Assignee | ||
Comment 5•14 years ago
|
||
(In reply to comment #2) > I have a copious amount of tabs open, probably about a 100, two app-tabs that > are self updating, namely zimbra & tbpl. 90% of my open tabs are bugzilla > pages, so there's nothing too exceptional about them. I'm not using tabcandy > for anything either. Hope that helps. I think TBPL sends out big JSON-like strings that get eval'd, which can generate huge code memory, making OOMs more likely. So TBPL/100-tabs-caused OOMs seems likely. I will make it not crash for this bug. We really need to avoid JSON-related code blowups, though too.
Assignee | ||
Comment 6•14 years ago
|
||
Attachment #490313 -
Flags: review?(dvander)
Updated•14 years ago
|
Attachment #490313 -
Flags: review?(dvander) → review+
Assignee | ||
Comment 7•14 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/fa18694814e7 http://hg.mozilla.org/mozilla-central/rev/95e9c2e8708d Will close when verified through Socorro.
Status: NEW → ASSIGNED
Comment 8•14 years ago
|
||
(In reply to comment #5) > I think TBPL sends out big JSON-like strings that get eval'd, which can > generate huge code memory, making OOMs more likely. So TBPL/100-tabs-caused > OOMs seems likely. I will make it not crash for this bug. We really need to > avoid JSON-related code blowups, though too. Will bug 577359 address this?
Assignee | ||
Comment 9•14 years ago
|
||
Fixed in builds from Nov 12 on.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•14 years ago
|
||
(In reply to comment #8) > (In reply to comment #5) > > I think TBPL sends out big JSON-like strings that get eval'd, which can > > generate huge code memory, making OOMs more likely. So TBPL/100-tabs-caused > > OOMs seems likely. I will make it not crash for this bug. We really need to > > avoid JSON-related code blowups, though too. > > Will bug 577359 address this? I believe so. Thanks for reminding of that bug number. I wanted to be sure to check that TBPL works well after it is fixed.
Updated•13 years ago
|
Crash Signature: [@ JSC::ExecutablePool::ExecutablePool(unsigned int) ]
You need to log in
before you can comment on or make changes to this bug.
Description
•