Closed Bug 718285 Opened 12 years ago Closed 12 years ago

crash during cycle collection traversal of nsDOMEvent::target

Categories

(Core :: DOM: Events, defect)

defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 718284

People

(Reporter: mccr8, Unassigned)

Details

(Keywords: crash)

Crash Data

There are a number of crashes with stacks that look like this:
0 	xul.dll 	GCGraphBuilder::NoteXPCOMChild 	xpcom/base/nsCycleCollector.cpp:1724
1 	xul.dll 	nsDOMEvent::cycleCollection::Traverse 	content/events/src/nsDOMEvent.cpp:239
2 	xul.dll 	nsCycleCollector::MarkRoots 	xpcom/base/nsCycleCollector.cpp:1920
The NoteXPComChild line is this:
   if (!child || !(child = canonicalize(child)))
The Traverse line is this:
   NS_IMPL_CYCLE_COLLECTION_TRAVERSE_NSCOMPTR(mEvent->target)

In 10 and 11, 5 users reported crashing here while searching for Wikipedia:
11:
"happens about 50% of time when I visit wikipedia through search box"
"This crash occurs every time I attempt to search Wikipedia via the search bar plugin. It does not occur when I use other searches from the same bar. It does not occur when I navigate to Wikipedia using the URL bar or search via the Wikipedia landing page."
"Problem with wikipedia. Crashes everytime after 2 seconds."
12:
"This crash (along with the one submitted from my same machine about 2.5 hours ago, and along with the previous six crashes for which I didn't submit crash reports) was triggered by entering something into the #nav-bar's search bar, then clicking/pressng enter to tell Firefox to search, with Wikipedia as the selected search engine. (It used to seem associated with alt-tabbed away while still loading, but in this case Firefox still had focus.)"
"Yet another crash after entering text into the search bar and searching with Wikipedia as the search engine."
The 4 that have any extensions listed all have HTTPS Everywhere 1.2.1 installed.  The latest version 1.2.2 lists "Fixes: Wikipedia, Identi.ca, Verizon, CCC.de, UserScripts, Yandex" in the patch notes.
https://crash-stats.mozilla.com/report/index/44f15c5a-a8f9-40e7-a73a-bec3d2120107
https://crash-stats.mozilla.com/report/index/8f05f424-ef7b-42f9-826b-486502120108
https://crash-stats.mozilla.com/report/index/7b4b8c80-3952-4cce-99f1-2be7d2120108
https://crash-stats.mozilla.com/report/index/6c08e4f9-3a8e-4489-8064-f31a42120109
https://crash-stats.mozilla.com/report/index/93a7025e-2131-4eee-86e4-5bf022120111

In bug 547987, some users reported similar crashes by reloading with ctrl-F5 on  html5test.com.  Out of the 8 or so crashes, two had the same stack as above:
https://crash-stats.mozilla.com/report/index/bp-eeea6096-5349-4700-bf87-f91572120114
https://crash-stats.mozilla.com/report/index/bp-47edcacb-2957-42ce-a72f-298852120114
Neither seemed to have HTTPS Everywhere.

Maybe there's enough info here to figure something out.
Severity: normal → critical
Crash Signature: [@ GCGraphBuilder::NoteXPCOMChild(nsISupports*)] [@ @0x0 | GCGraphBuilder::NoteXPCOMChild(nsISupports*)]
Keywords: crash
I can reproduce this by refreshing html5test.com repeatedly.  The first time, it crashed in XPCWrappedNative::FlatJSObjectFinalized:
https://crash-stats.mozilla.com/report/index/bp-fc58a09a-6417-4d6f-bf78-9bed82120115
The second time it crashed in NoteXPCom as noted above:
https://crash-stats.mozilla.com/report/index/bp-6752526e-79a6-4e6b-9c17-21a122120115
This is similar behavior as was reported in bug 547987.

I don't know if this is related to the Wikipedia thing or not, maybe it should be a separate bug.
Bug 718284 is the same thing, but with detailed steps to reproduce the HTTPS Everywhere thing. I think I'll file a separate bug for HTML5test crashing.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
No longer blocks: 469267
You need to log in before you can comment on or make changes to this bug.