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

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[beingalink]

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.

Comment 1

[beingalink]

It's important to mention that I'm on the yosemite beta. Sorry for not mentioning it in the beginning.

Comment 2

[beingalink]

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

Comment 3

[Ralph Giles (:rillian)]

Can you got to about:crashes and paste a link to the corresponding backtrace?

Comment 4

[beingalink]

https://crash-stats.mozilla.com/report/index/bp-4509f372-5b2c-4df8-8f42-7118e2140801

https://crash-stats.mozilla.com/report/index/bp-8fcd3888-7972-478e-a9c7-121712140801

https://crash-stats.mozilla.com/report/index/bp-f2b6825e-5cbc-462f-a3d0-0426f2140801

these should be identical

Comment 5

[Ralph Giles (:rillian)]

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?

Comment 6

[beingalink]

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.

Comment 7

[Alex]

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

Comment 8

[:Gijs (he/him)]

(confirming based on the number of comments)

Comment 9

[Ralph Giles (:rillian)]

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.

Comment 10

[beingalink]

@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.

Comment 11

[Ralph Giles (:rillian)]

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.

Comment 12

[:kip (Kearwood Gilbert)]

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.

Comment 13

[Ralph Giles (:rillian)]

Thanks, kip. I guess we can conclude it's specific to 10.10.

Comment 14

[Ralph Giles (:rillian)]

I've been able to reproduce on a loaner Mid 201 11-inch MacBook Air running 10.10.

Comment 15

[u408661]

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)

Comment 16

[Ralph Giles (:rillian)]

That looks like a different bug, unless there's memory corruption involved. Can you share a specific youtube url which reliably crashes?

Comment 17

[u408661]

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.

Comment 18

[Ralph Giles (:rillian)]

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

Comment 19

[Ralph Giles (:rillian)]

ConvertByteRangesToTime() is being called on a null MP4Demuxer::mPrivate::mVideoIndex. I suspect this is a new bug shadowing the 10.10-only one.

Comment 20

[Ralph Giles (:rillian)]

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?

Comment 21

[beingalink]

I'm on 2014-08-14 Nightly and I still get this crash instantly.

Comment 22

[Alex]

Still crashes for me as well, trying to play a video off my drive.

bp-207c1f31-38b7-473e-9bc6-0e2c82140814

Comment 23

[Ralph Giles (:rillian)]

Attachment: Part 1: Don't crash on null VideoData

This doesn't fix playback, but should at least avoid the crash.

Comment 24

[Ralph Giles (:rillian)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f16ba9b456d1

Comment 25

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f16ba9b456d1

Comment 26

[beingalink]

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).

Comment 27

[beingalink]

Attachment: Screenshot 2014-08-17 20.33.43.png

Comment 28

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

\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.

Comment 29

[Ralph Giles (:rillian)]

Thanks for confirming. The duration issue is bug 1050814.

I've filed bug 1054789 to follow up on the decoding issue.