Closed
Bug 941701
Opened 12 years ago
Closed 12 years ago
[WebVTT] Crash in [@ mozilla::dom::TextTrackCue::GetCueAsHTML()]
Categories
(Core :: Audio/Video, defect)
Tracking
()
VERIFIED
FIXED
mozilla30
People
(Reporter: alicoding, Assigned: reyre)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
1.84 KB,
patch
|
rillian
:
review+
lsblakk
:
approval-mozilla-aurora+
lsblakk
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
https://crash-stats.mozilla.com/report/index/a2241395-f19c-464e-b8a0-592372131121
http://rickeyre.ca/2013/06/20/webvtt-cycle-collector-demo.html
I crash watching this demo on your blog
I'm using Firefox Nightly build 28.0a1 (2013-11-21) On Mavericks 10.9
Comment 1•12 years ago
|
||
I can't _consistently_ reproduce this on linux, however a combination of pausing the video, reloading the page and attempting to play again after another pause does trigger this crash.
Comment 2•12 years ago
|
||
Here is another crash report from what seems to be the same bug:
https://crash-stats.mozilla.com/report/index/01f8bd43-00b8-4ef4-b4e3-728132131205
The crash occurs fairly consistently after watching videos at http://tvthek.orf.at/ or http://mediathek.daserste.de/ - maybe sending the videos to fullscreen has something to do with it (I was granting these 2 sites fullscreen permissions when I stumbled upon these crashes).
Updated•12 years ago
|
Crash Signature: [@ mozilla::dom::TextTrackCue::GetCueAsHTML() ]
![]() |
Assignee | |
Updated•12 years ago
|
Assignee: nobody → rick.eyre
![]() |
Assignee | |
Comment 3•12 years ago
|
||
Looking at the crash report it looks like getCueAsHTML is running while the HTMLMediaElement is being unbound from the tree. That's probably resulting in it trying to access something that no longer exists. We've had issues like this before while the cycle collector runs.
Comment 4•12 years ago
|
||
(In reply to Rick Eyre (:reyre) from comment #3)
> Looking at the crash report it looks like getCueAsHTML is running while the
> HTMLMediaElement is being unbound from the tree. That's probably resulting
> in it trying to access something that no longer exists. We've had issues
> like this before while the cycle collector runs.
Indeed it looks like these crashes occur usually a while (can be up to a few minutes I guess) after subtitles were involved, and seemingly random (doesn't crash every time). This makes cycle collector very plausible, like if these 2 events happen to fall together, Firefox crashes.
![]() |
Assignee | |
Comment 5•12 years ago
|
||
I'm having a hard time reproducing this on the current tree. The code around this crash recently changed. Can you reproduce anymore Andrew?
Flags: needinfo?(andrew.quartey)
Comment 6•12 years ago
|
||
Can you reproduce anymore Andrew?
I'll look into it and let you know.
Flags: needinfo?(andrew.quartey)
Comment 7•12 years ago
|
||
I can easily reproduce this issue with Firefox 28 beta 3 (Build ID: 20140213172947) on Mac OS X 10.8.5 and Ubuntu 13.10 x64 with the same STR as in comment 1 and https://people.xiph.org/~giles/2013/vtt-01.html video.
On Windows 7 x64 I get a different crash signature: https://crash-stats.mozilla.com/report/index/d0ad6693-6cb5-4272-b2e8-374e12140214
No crashes encountered with latest Aurora and Nightly builds.
Blocks: webvtt
Comment 8•12 years ago
|
||
Thanks for reproducing, Alexandra! I cannot reproduce with 28 beta 2 on MacOS X 10.8.5. Will try beta 3.
Is your crash signature on mac the same as comment 1? Can you get a backtrace from a debug build?
Comment 9•12 years ago
|
||
I can reproduce with 28 beta 3. I used https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/28.0b3-candidates/build1/mac/en-GB/Firefox%2028.0b3.dmg Build id 20140213172947 as in comment 7.
https://crash-stats.mozilla.com/report/index/ea5120c9-41b7-4969-a25d-445e42140214
![]() |
Assignee | |
Comment 10•12 years ago
|
||
Seems to have fixed the crash for me.
TextTrackCue::GetCueAsHTML gets called when the HTMLMediaElement
shutsdown which means that TextTrackCues Document sometimes no longer
exists based on when the cycle collector freed it. I've added a null
check to make sure that it exists before we start doing anything.
Attachment #8376373 -
Flags: review?(giles)
![]() |
Assignee | |
Comment 11•12 years ago
|
||
I believe it's not reproducible on Nightly or Aurora because the TextTrack rendering algorithm no longer calls GetCueAsHTML. It goes though a different path. So just playing a video is no longer sufficient to cause this crash in Nightly or Aurora.
Updated•12 years ago
|
Attachment #8376373 -
Flags: review?(giles) → review+
![]() |
Assignee | |
Comment 12•12 years ago
|
||
Comment on attachment 8376373 [details] [diff] [review]
v1: Fix crash in TextTrackCue::GetCueAsHTML r=rillian
[Approval Request Comment]
Bug caused by (feature/regressing bug #): WebVTT
User impact if declined: Crashes when watching WebVTT
Testing completed (on m-c, etc.): Manual
Risk to taking this patch (and alternatives if risky): No risk really. We've just added a null check for the TextTrackCue's document.
Attachment #8376373 -
Flags: approval-mozilla-aurora?
![]() |
Assignee | |
Comment 13•12 years ago
|
||
Comment on attachment 8376373 [details] [diff] [review]
v1: Fix crash in TextTrackCue::GetCueAsHTML r=rillian
[Approval Request Comment]
Bug caused by (feature/regressing bug #): WebVTT
User impact if declined: Crashes when watching WebVTT
Testing completed (on m-c, etc.): Manual
Risk to taking this patch (and alternatives if risky): No risk really. We've just added a null check for the TextTrackCue's document.
Attachment #8376373 -
Flags: approval-mozilla-beta?
Comment 14•12 years ago
|
||
Updated•12 years ago
|
status-firefox27:
--- → unaffected
status-firefox28:
--- → affected
status-firefox29:
--- → affected
tracking-firefox28:
--- → ?
tracking-firefox29:
--- → ?
Comment 15•12 years ago
|
||
I will wait for the patch to land in m-c before uplifting it.
Updated•12 years ago
|
status-firefox30:
--- → affected
tracking-firefox30:
--- → +
Comment 16•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Updated•12 years ago
|
Attachment #8376373 -
Flags: approval-mozilla-beta?
Attachment #8376373 -
Flags: approval-mozilla-beta+
Attachment #8376373 -
Flags: approval-mozilla-aurora?
Attachment #8376373 -
Flags: approval-mozilla-aurora+
Comment 17•12 years ago
|
||
![]() |
Assignee | |
Comment 18•12 years ago
|
||
Thanks for landing those in Aurora and Beta, Ryan.
Comment 19•12 years ago
|
||
Updated•12 years ago
|
status-b2g-v1.3:
--- → fixed
status-b2g-v1.4:
--- → fixed
Comment 20•12 years ago
|
||
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
Mozilla/5.0 (X11; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:28.0) Gecko/20100101 Firefox/28.0
Verified as fixed with Firefox 28 beta 4 (Build ID: 20140218122424).
Comment 21•12 years ago
|
||
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:29.0) Gecko/20100101 Firefox/29.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101 Firefox/30.0
Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0
Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:30.0) Gecko/20100101 Firefox/30.0
Verified as fixed with latest Aurora (Build ID: 20140306004001) and Nightly (Build ID: 20140306030201).
Status: RESOLVED → VERIFIED
Keywords: verifyme
Updated•12 years ago
|
status-b2g-v1.3T:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•