Closed Bug 466607 Opened 17 years ago Closed 17 years ago

Shutdown crash due to non-HTML <video> element

Categories

(Core :: Audio/Video, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: jruderman, Assigned: dholbert)

References

Details

(Keywords: crash, testcase, verified1.9.1, Whiteboard: [sg:critical])

Attachments

(4 files, 1 obsolete file)

Steps to reproduce: 1. Load the testcase. 2. Wait a few hundred milliseconds. 3. Quit Firefox with Cmd+Q. Result: Crash on shutdown, 50% of the time. Most of the crashes happen during XPCWrappedNative::FlatJSObjectFinalized (during GC), but sometimes they happen during nsHTMLMediaElement::Freeze instead. Both types of crashes appear [sg:critical]. The second crash signature makes me suspicious: why is an nsHTMLMediaElement is being created here, given that the "video" element isn't in the HTML namespace?
Flags: blocking1.9.1?
Whiteboard: [sg:critical]
Flags: blocking1.9.1? → blocking1.9.1+
This happens on Linux as well, though it's a load-time crash rather than a shutdown crash. (Crash still only happens ~50% of the time, though) I initially filed bug 467621 for the linux load-time crashes, but then I noticed both bugs' crashes are within nsHTMLMediaElement::Freeze, so it's probably the same root cause. Crash reports for Linux crashes: * In [ nsGenericElement::HasAttributes ]: http://crash-stats.mozilla.com/report/index/0d42a2da-d995-46ad-9119-05daf2081202 http://crash-stats.mozilla.com/report/index/32d7ade1-86e5-4a77-9e8d-431472081202 http://crash-stats.mozilla.com/report/index/10f891fb-46f2-4cba-b97d-a04182081202 * In [ @0xaf4b3aa4 ]: http://crash-stats.mozilla.com/report/index/9796f2b7-522a-4623-b8a4-71e432081202
OS: Mac OS X → All
Hardware: PC → All
Just caught the crash in GDB. It looks like we're calling StopMediaInstance() with aContent pointing to a nsXMLElement, but that function static_casts it to a nsHTMLMediaElement. And then we lose. URL: http://tinyurl.com/6m5lpo
OS: All → Mac OS X
Hardware: All → PC
So basically, we're assuming that all elements with tag name = "video" are nsHTMLMediaElements, which isn't true in this case. Specifically, we do this: * Call EnumeratePlugins(domDoc, NS_LITERAL_STRING("video"), StopMediaInstance); * EnumeratePlugins dutifully looks up all DOM nodes that have tag name = "video", which in this case includes a non-HTML element. It calls StopMediaInstance on all these elements. * StopMediaInstance kills us because it assumes its input to be a nsHTMLMediaElement, which in this case it isn't. (It looks we could probably hit this bug with <audio>, too, FWIW.)
OS: Mac OS X → All
Hardware: PC → All
This testcase crashes for me some of the time too, just like the first one. It just crashed during GC for me -- not during nsHTMLMediaElement::Freeze. I'm guessing this is because refcounting can get screwed up when we cast a non-HTML-element to be a nsHTMLMediaElement. (which we do here, as mentioned above)
Attachment #349927 - Attachment description: testcase (can cause shutdown crash) → testcase with <video> (can cause shutdown crash)
Attached patch patch v1 (obsolete) — Splinter Review
This patch fixes the issue by tweaking StopMediaInstance (and the related StartMediaInstance) to only static_cast if the node is HTML. (as reported by "IsNodeOfType(nsINode::eHTML)") If that check succeeds, we know it's (a) a HTML element, and (b) it's tag is either "video" or "audio" (otherwise we wouldn't be inside this function), which AFAIK means it's safe to assume it's a nsHTMLMediaElement.
We don't need those warnings. Also, I think it would be slightly better to QI to nsIDOMHTMLMediaElement instead of doing the IsNodeOfType check.
Attachment #351071 - Flags: superreview?(roc)
Attachment #351071 - Flags: review?(chris.double)
Blocks: 449518
Attachment #351071 - Flags: superreview?(roc)
Attachment #351071 - Flags: review?(chris.double)
Attached patch patch v2Splinter Review
With warning removed, & using QI instead of IsNodeOfType.
Attachment #351071 - Attachment is obsolete: true
Attachment #351076 - Flags: superreview?(roc)
Attachment #351076 - Flags: review?(chris.double)
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
Attachment #351076 - Flags: superreview?(roc) → superreview+
Attachment #351076 - Flags: review?(chris.double) → review+
Whiteboard: [sg:critical] → [sg:critical] [needs landing]
patch v2 pushed to mozilla-central as changeset d5969f0d3fd9
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [sg:critical] [needs landing] → [sg:critical] [needs 1.9.1 landing]
Keywords: fixed1.9.1
Whiteboard: [sg:critical] [needs 1.9.1 landing] → [sg:critical]
Target Milestone: --- → mozilla1.9.1b3
Verified fixed on trunk and 1.9.1 with builds on OS X and Windows: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090204 Shiretoko/3.1b3pre ID:20090204034421 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090204 Minefield/3.2a1pre ID:20090204032912
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Target Milestone: mozilla1.9.1b3 → mozilla1.9.2a1
Flags: wanted1.9.0.x-
Flags: wanted1.8.1.x-
Group: core-security
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: