Closed Bug 605752 Opened 10 years ago Closed 9 years ago

crash [@ JSC::ExecutablePool::ExecutablePool(unsigned int) ]

Categories

(Core :: JavaScript Engine, defect, critical)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta8+

People

(Reporter: scoobidiver, Assigned: dmandelin)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

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: general → dmandelin
blocking2.0: ? → beta8+
(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.
Attached patch PatchSplinter Review
Attachment #490313 - Flags: review?(dvander)
Attachment #490313 - Flags: review?(dvander) → review+
http://hg.mozilla.org/tracemonkey/rev/fa18694814e7
http://hg.mozilla.org/mozilla-central/rev/95e9c2e8708d

Will close when verified through Socorro.
Status: NEW → ASSIGNED
(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?
Fixed in builds from Nov 12 on.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(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.
Depends on: 636487
Crash Signature: [@ JSC::ExecutablePool::ExecutablePool(unsigned int) ]
You need to log in before you can comment on or make changes to this bug.