626599 - Crash mainly at startup [@ js_SetDebugMode ]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Scoobidiver (away)]

It is a new crash signature. Crashes first appeared in 4.0b10pre/20110115.
It is #9 top crasher for the last 3 days.

Some comments say that they tried to launch FF with -chromebug option.

Signature	js_SetDebugMode
UUID	bd33f220-dd70-4bbc-b90e-bb7892110117
Time 	2011-01-17 14:29:51.693523
Uptime	4
Last Crash	151 seconds before submission
Install Age	17243 seconds (4.8 hours) since version was first installed.
Product	Firefox
Version	4.0b10pre
Build ID	20110117030328
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 6
Crash Reason	EXCEPTION_ACCESS_VIOLATION_WRITE
Crash Address	0xa5c
User Comments	Trying to launch with -chromebug
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0425

Frame 	Module 	Signature [Expand] 	Source
0 	mozjs.dll 	js_SetDebugMode 	js/src/jsdbgapi.cpp:144
1 	xul.dll 	jsdService::RecompileForDebugMode 	js/jsd/jsd_xpc.cpp:2517
2 	xul.dll 	jsdService::ActivateDebugger 	js/jsd/jsd_xpc.cpp:2531
3 	xul.dll 	nsThread::ProcessNextEvent 	
4 	setupapi.dll 	_imp_load__GetExplicitEntriesFromAclW 	
5 	frozen.dll 	frozen.dll@0xe6766 	
6 	frozen.dll 	frozen.dll@0xe732c 	
7 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
8 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
9 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:202
10 	mozcrt19.dll 	_VEC_memzero 	
11 	xul.dll 	xul.dll@0x35895d 	
12 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:176
13 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:192
14 	xul.dll 	xul.dll@0xb1ff6b 	
15 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:217
16 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3699
17 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:128
18 	firefox.exe 	__tmainCRTStartup 	obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591
19 	kernel32.dll 	BaseThreadInitThunk 	
20 	ntdll.dll 	__RtlUserThreadStart 	
21 	ntdll.dll 	_RtlUserThreadStart 	

The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f412256da4c&tochange=3d4620449437

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=js_SetDebugMode

Comment 1

[Luke Wagner [:luke]]

Attachment: check cx->compartment

From the crash address it looks like cx-compartment is NULL, which seems like a valid state in this context.

Andreas: looking at jsdService::RecompileForDebugMode, it looks like we iterate over all contexts, setting debug mode on their compartments.  Won't this miss every compartment we are not currently executing in?

Comment 2

[Andreas Gal :gal]

Comment on attachment 504737 [details] [diff] [review]
check cx->compartment

Yes, compartment can be NULL when we are not executing. And yes, we can miss compartments that way. It would be safer to iterate over all compartments.

Comment 3

[Luke Wagner [:luke]]

(In reply to comment #2)
> Yes, compartment can be NULL when we are not executing. And yes, we can miss
> compartments that way. It would be safer to iterate over all compartments.

If, by precondition, no code is running, it seems that practically all compartments will be missed...

Comment 4

[Luke Wagner [:luke]]

http://hg.mozilla.org/tracemonkey/rev/fd3f307b70a2

(Filed bug 626743 for the comment 1 issue.)

Comment 5

[Chris Leary [:cdleary] (not checking bugmail)]

cdleary-bot mozilla-central merge info:
http://hg.mozilla.org/mozilla-central/rev/fd3f307b70a2