Closed Bug 1047486 Opened 5 years ago Closed 5 years ago

youtube makes firefox crash on OS X 10.10 with platform decoder exposed

Categories

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

34 Branch
x86
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla34

People

(Reporter: beingalink, Assigned: rillian)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Firefox/34.0 (Beta/Release)
Build ID: 20140801030201

Steps to reproduce:

I set media.fragmented-mp4.exposed to true, restarted firefox and visited youtube. I started to play a video there.


Actual results:

Firefox crashes.


Expected results:

The video should play.
It's important to mention that I'm on the yosemite beta. Sorry for not mentioning it in the beginning.
Perhaps this console information helps:

01.08.14 18:37:14,000 kernel[0]: firefox (map: 0xffffff801e0b2f00) triggered DYLD shared region unnest for map: 0xffffff801e0b2f00, region 0x7fff9a000000->0x7fff9a200000. While not abnormal for debuggers, this increases system memory footprint until the target exits.
01.08.14 18:37:14,074 firefox[44370]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.0 instead of 10.10.0. Use NSProcessInfo's operatingSystemVersion property to get correct system version number.
Call location:
01.08.14 18:37:14,101 firefox[44370]: 0   CarbonCore                          0x00007fff8db0706b ___Gestalt_SystemVersion_block_invoke + 113
01.08.14 18:37:14,101 firefox[44370]: 1   libdispatch.dylib                   0x00007fff8e030f53 _dispatch_client_callout + 8
01.08.14 18:37:14,101 firefox[44370]: 2   libdispatch.dylib                   0x00007fff8e030eb0 dispatch_once_f + 79
01.08.14 18:37:14,102 firefox[44370]: 3   CarbonCore                          0x00007fff8daaf53a _Gestalt_SystemVersion + 987
01.08.14 18:37:14,102 firefox[44370]: 4   CarbonCore                          0x00007fff8daaf127 Gestalt + 144
01.08.14 18:37:14,102 firefox[44370]: 5   XUL                                 0x0000000103b8f243 _ZN23nsNativeAppSupportCocoa5StartEPb + 35
01.08.14 18:37:14,102 firefox[44370]: 6   XUL                                 0x0000000103b80d11 _ZN7XREMain15XRE_mainStartupEPb + 289
01.08.14 18:37:14,210 gkbisd[186]: Unable to collect cdhash for /Applications/FirefoxNightly.app (error code -67028)
01.08.14 18:42:28,190 firefox[44370]: BUG in libdispatch: 14A299l - 993 - 0xe
Can you got to about:crashes and paste a link to the corresponding backtrace?
Thanks. These all crash in the ReorderQueue::Push call from AppleVTDecoder::OutputFrame().

I can't reproduce with youtube and a debug build; it serves me vp9 and aac so the video decoder isn't active. Can you share a specific url that crashes for you?
I don't think it matters what video I select. It just happened here: https://www.youtube.com/watch?v=OlWat9zmnHw It instantly crashes so I can't find out which codecs it uses.
I hit this same crash on any MP4 video, local or remote. And I'm also running the Yosemite beta.

https://crash-stats.mozilla.com/report/index/7ee8d37b-a67d-4e93-9007-a8af82140802
Severity: normal → critical
Keywords: crash
Crash Signature: [@ nsTPriorityQueue<mozilla::VideoData*, mozilla::ReorderQueueComparator>::Push(mozilla::VideoData* const&) ]
(confirming based on the number of comments)
Blocks: 941296
Status: UNCONFIRMED → NEW
Component: Untriaged → Video/Audio
Ever confirmed: true
Product: Firefox → Core
I still can't reproduce on Nightly or my own debug builds, MacOS X 10.8.5.

I can get youtube to serve me (non-dash) mp4 if I set

  media.mediasource.enabled = false
  media.fragmented-mp4.enabled = true

But it doesn't crash for me. This will be hard to debug without a video which reproduces.
@Ralph Giles
The keys/values you mention are the default values for me. I additionally have media.fragmented-mp4.exposed set to "true". And I guess it might have sth. to do with Yosemite.
Oops, yes. I also tested with media.fragmented-mp4.exposed = true. Otherwise I get webm from youtube.

I also tried Nightly on a 10.9.4 iMac and couldn't reproduce. Maybe it's specific to 10.10.
Reproduced on OSX 10.10 DP5 with Nightly 34.0a1 (2014-08-05).  After crashing once, it was necessary to clear browser history to reproduce the issue a second time.
Thanks, kip. I guess we can conclude it's specific to 10.10.
Summary: youtube makes firefox crash on OS X with platform decoder exposed → youtube makes firefox crash on OS X 10.10 with platform decoder exposed
I've been able to reproduce on a loaner Mid 201 11-inch MacBook Air running 10.10.
Depends on: 1044497
It's not the same stack, but I have been able to get a crash on 10.9.4 just by setting media.fragmented-mp4.exposed to true and attempting to watch a youtube video: https://crash-stats.mozilla.com/report/index/2f6a6753-2552-4dc0-957c-f8e292140808 (and it seems others have with the same stack as me, too: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=mp4_demuxer%3A%3AIndex%3A%3AConvertByteRangesToTimeRanges%28nsTArray%3Cmozilla%3A%3AMediaByteRange%3E+const%26%2C+nsTArray%3Cmp4_demuxer%3A%3AInterval%3Clong+long%3E+%3E*%29#tab-reports)
That looks like a different bug, unless there's memory corruption involved. Can you share a specific youtube url which reliably crashes?
Sadly... no, it seems I can not. Every one I try now works just fine (of course). No changes to my profile or build or anything, everything "just works". I'll file a new bug if I find something reproduceable.
So the good news is that the JSConf video is crashing on 10.8 for me today. The bad news is it's a different backtrace, so we probably have memory corruption.

nsAutoPtr<MoofParser>::mRawPtr is 40.

* thread #1: tid = 0xd6a6c, 0x00000001015b419c XUL`nsAutoPtr<mp4_demuxer::MoofParser>::get(this=0x0000000000000040) const + 12 at nsAutoPtr.h:137, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x40)
  * frame #0: 0x00000001015b419c XUL`nsAutoPtr<mp4_demuxer::MoofParser>::get(this=0x0000000000000040) const + 12 at nsAutoPtr.h:137
    frame #1: 0x00000001015ac9e5 XUL`nsAutoPtr<mp4_demuxer::MoofParser>::operator mp4_demuxer::MoofParser*(this=0x0000000000000040) const + 21 at nsAutoPtr.h:151
    frame #2: 0x0000000101595933 XUL`mp4_demuxer::Index::ConvertByteRangesToTimeRanges(this=0x0000000000000000, aByteRanges=0x00007fff5fbfc9b8, aTimeRanges=0x00007fff5fbfc9a8) + 67 at Index.cpp:93
    frame #3: 0x000000010159815b XUL`mp4_demuxer::MP4Demuxer::ConvertByteRangesToTime(this=0x000000012a228680, aByteRanges=0x00007fff5fbfc9b8, aIntervals=0x00007fff5fbfc9a8) + 171 at mp4_demuxer.cpp:210
    frame #4: 0x0000000104451783 XUL`mozilla::MP4Reader::NotifyDataArrived(this=0x000000012b8e2400, aBuffer=0x000000012a56f000, aLength=16384, aOffset=393708) + 195 at MP4Reader.cpp:754
ConvertByteRangesToTime() is being called on a null MP4Demuxer::mPrivate::mVideoIndex. I suspect this is a new bug shadowing the 10.10-only one.
I can no longer reproduce with today's tree or Nightly build now that bug 1050060 is fixed. Maybe that was the problem all along?

Beingalink, can you confirm with a 2014-08-14 or later Nightly?
Assignee: nobody → giles
Depends on: 1050060
Flags: needinfo?(beingalink)
I'm on 2014-08-14 Nightly and I still get this crash instantly.
Flags: needinfo?(beingalink)
Still crashes for me as well, trying to play a video off my drive.

bp-207c1f31-38b7-473e-9bc6-0e2c82140814
This doesn't fix playback, but should at least avoid the crash.
Attachment #8473798 - Flags: review?(cpearce)
Attachment #8473798 - Flags: review?(cpearce) → review+
https://hg.mozilla.org/mozilla-central/rev/f16ba9b456d1
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
I can confirm that the crashing is fixed. Audio on youtube plays fine but the video stays black. There seems to be some issue with timing (see attachment).
\o/

(In reply to beingalink from comment #26)
> There seems to be some issue with timing (see attachment).

The incorrect duration is unrelated to this bug. See bug 1050814.
Thanks for confirming. The duration issue is bug 1050814.

I've filed bug 1054789 to follow up on the decoding issue.
Status: RESOLVED → VERIFIED
Depends on: 1054789
Blocks: 1054789
No longer depends on: 1054789
You need to log in before you can comment on or make changes to this bug.