787887 - crash in jsd_ClearAllExecutionHooksForScript @ js::detail::HashTable

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Scoobidiver (away)]

It's #41 top browser crasher in 16.0b1.

Here are some correlations per extension in 16.0:
     82% (46/56) vs.   0% (81/31644) {81BF1D23-5F17-408D-AC6B-BD6DF7CAF670} (iMacros for Firefox, https://addons.mozilla.org/addon/3863)
     54% (30/56) vs.   7% (2139/31644) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865)
     36% (20/56) vs.   1% (230/31644) [e-mail] (Adblock Plus: Element Hiding Helper, https://addons.mozilla.org/addon/4364)
     34% (19/56) vs.   0% (19/31644) [e-mail] (Go2 proxy, https://addons.mozilla.org/addon/10815)
     34% (19/56) vs.   0% (129/31644) [e-mail] (Ghostery, https://addons.mozilla.org/addon/9609)
     34% (19/56) vs.   1% (195/31644) {d40f5e7b-d2cf-4856-b441-cc613eeffbe3} (BetterPrivacy, https://addons.mozilla.org/addon/6623)
     18% (10/56) vs.   0% (101/31644) {3d7eb24f-2740-49df-8937-200b1cc08f8a} (Flashblock, https://addons.mozilla.org/addon/433)
     16% (9/56) vs.   0% (10/31644) [e-mail] (Flash Killer, https://addons.mozilla.org/addon/5842)
     16% (9/56) vs.   1% (178/31644) [e-mail]
     16% (9/56) vs.   1% (349/31644) [e-mail] (Firebug, https://addons.mozilla.org/addon/1843)
     13% (7/56) vs.   0% (66/31644) {003e1c8f-ebd6-f074-7551-4b31c0f547ec}

Signature 	js::detail::HashTable<js::HashMapEntry<JSScript*, js::DebugScript*>, js::HashMap<JSScript*, js::DebugScript*, js::DefaultHasher<JSScript*>, js::SystemAllocPolicy>::MapHashPolicy, js::SystemAllocPolicy>::lookup(JSScript* const&, unsigned int, unsigned int) More Reports Search
UUID	565b14b2-0cd5-4636-b636-895a52120903
Date Processed	2012-09-03 08:03:05
Uptime	8795
Last Crash	3.9 days before submission
Install Age	3.2 hours since version was first installed.
Install Time	2012-09-03 04:50:01
Product	Firefox
Version	16.0
Build ID	20120828083259
Release Channel	beta
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 37 stepping 5
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x0
App Notes 
Cisco VPN
AdapterVendorID: 0x8086, AdapterDeviceID: 0x0042, AdapterSubsysID: 00368086, AdapterDriverVersion: 8.15.10.2622
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ 
Processor Notes 	This dump is too long and has triggered the automatic truncation routine
EMCheckCompatibility	True
Adapter Vendor ID	0x8086
Adapter Device ID	0x0042
Total Virtual Memory	4294836224
Available Virtual Memory	3583971328
System Memory Use Percentage	65
Available Page File	4733267968
Available Physical Memory	1410277376

Frame 	Module 	Signature 	Source
0 	mozjs.dll 	js::detail::HashTable<js::HashMapEntry<JSScript*,js::DebugScript*>,js::HashMap<J 	obj-firefox/dist/include/js/HashTable.h:445
1 	mozjs.dll 	js::detail::HashTable<js::HashMapEntry<JSScript*,js::DebugScript*>,js::HashMap<J 	obj-firefox/dist/include/js/HashTable.h:734
2 	mozjs.dll 	JSScript::debugScript 	js/src/jsscript.cpp:1879
3 	mozjs.dll 	JSScript::getBreakpointSite 	js/src/jsscript.h:847
4 	mozjs.dll 	JSScript::clearTraps 	js/src/jsscript.cpp:2082
5 	mozjs.dll 	JS_ClearScriptTraps 	js/src/jsdbgapi.cpp:212
6 	xul.dll 	jsd_ClearAllExecutionHooksForScript 	js/jsd/jsd_scpt.c:934
7 	xul.dll 	jsd_ClearAllExecutionHooks 	js/jsd/jsd_scpt.c:948
8 	xul.dll 	jsdService::ClearAllBreakpoints 	js/jsd/jsd_xpc.cpp:3030
9 	xul.dll 	jsdService::DeactivateDebugger 	js/jsd/jsd_xpc.cpp:2540
10 	xul.dll 	jsdService::Off 	js/jsd/jsd_xpc.cpp:2649
11 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:70
12 	xul.dll 	XPCWrappedNative::CallMethod 	js/xpconnect/src/XPCWrappedNative.cpp:2418
13 	xul.dll 	XPC_WN_CallMethod 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1474
14 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:344
15 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:2442
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Adetail%3A%3AHashTable%3Cjs%3A%3AHashMapEntry%3CJSScript*%2C+js%3A%3ADebugScript*%3E%2C+js%3A%3AHashMap%3CJSScript*%2C+js%3A%3ADebugScript*%2C+js%3A%3ADefaultHasher%3CJSScript*%3E%2C+js%3A%3ASystemAllocPolicy%3E%3A%3AMapHashPolicy%2C+js%3A%3ASystemAllocPolicy%3E%3A%3Alookup%28JSScript*+const%26%2C+unsigned+int%2C+unsigned+int%29

Comment 1

[Naveed Ihsanullah [:naveed]]

Lifetime related to DebugScriptMap items?

http://hg.mozilla.org/releases/mozilla-beta/diff/cdd78230db65/js/src/jsscript.cpp#l1.49

Comment 2

[Nicholas Nethercote [inactive]]

Luke:  Is it possible for a JSScript to move from one compartment to another?

----

They're all NULL crashes, and all the reports I looked at had exactly the same stack trace, which is good.

The crashing line is this:

  HashNumber h1 = hash1(keyHash, hashShift);

hash1() is just this:

    static HashNumber hash1(HashNumber hash0, uint32_t shift) {
        return hash0 >> shift;  
    }

which is almost certainly inlined.

The only memory access taking place is the read of |hashShift|, which is the first field in HashTable.  So it looks like the HashTable is NULL.

That means in JSScript::Script() when we do this:

  1879    DebugScriptMap::Ptr p = map->lookup(this);

|map| must be NULL.  (Which is annoying, because we do |JS_ASSERT(map);| immediately prior.)  Which means that |compartment()->debugScriptMap| must also be NULL.

Going back a frame to JSScript::getBreakpointSite(), |script->hasDebugScript| must be true.  But I don't see how that can be true for a script while |compartment()->debugScriptMap| can be false for the script's compartment.  Unless a script can migrate between compartments...?






e're calling |map->lookup()| when |map| is NULL, which suggests that |compartment->debugScriptMap| is NULL.  But in that case |script->hasDebugScriptMap| should be NULL, in which case we would not call |compartments->debugScript()|.

There are also numerous assertions in that code to catch any problems of this kind, not that that's much help in release builds.  Hmm.

Comment 3

[Nicholas Nethercote [inactive]]

(Sorry, just ignore the two paragraphs at the bottom of comment 2.)

Comment 4

[Luke Wagner [:luke]]

(In reply to Nicholas Nethercote [:njn] from comment #2)
> Luke:  Is it possible for a JSScript to move from one compartment to another?

No, they get cloned.

Comment 5

[Nicholas Nethercote [inactive]]

> > Luke:  Is it possible for a JSScript to move from one compartment to another?
> 
> No, they get cloned.

Hmm, for a minute I was certain that cloning would be the problem here -- that we wouldn't be adjusting |compartment()->debugScriptMap| for the clone.  But we don't set |hasDebugScript| in the cloned script, so that shouldn't be it.  I also looked at the XDR code, but we don't set or restore |hasDebugScript| there either.  Am I missing something?

Comment 7

[Nicholas Nethercote [inactive]]

From mid- to late-September this crash was happening dozens of times a day.  Since September 29 it's been much less frequent, e.g. 0..5 times a day.  I'm not sure how to interpret that.

Comment 8

[Scoobidiver (away)]

(In reply to Nicholas Nethercote [:njn] from comment #7)
> From mid- to late-September this crash was happening dozens of times a day. 
> Since September 29 it's been much less frequent, e.g. 0..5 times a day.  I'm
> not sure how to interpret that.
The signature morphs regularly. See https://crash-stats.mozilla.com/query/query?product=Firefox&version=ALL%3AALL&query_type=startswith&query=js%3A%3Adetail%3A%3AHashTable%3Cjs%3A%3AHashMapEntry&do_query=1

Comment 9

[Nicholas Nethercote [inactive]]

I will be optimistic and assume this has gone away, since this bug hasn't been touched in 2.5 years. Please reopen if that is incorrect.