Closed Bug 1055694 Opened 6 years ago Closed 6 years ago

Crashes in AppleVA private framework in mozilla::AppleVTDecoder::InitializeSession() on OS X 10.9 and up

Categories

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

All
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla35
Tracking Status
firefox32 --- unaffected
firefox33 --- unaffected
firefox34 + fixed
firefox35 + fixed

People

(Reporter: mossop, Assigned: rillian)

References

Details

(Keywords: crash, reproducible, topcrash-mac, Whiteboard: [STR in comment #32])

Crash Data

Attachments

(4 files, 1 obsolete file)

This bug was filed from the Socorro interface and is 
report bp-3b45c702-b3b5-4a11-9f0d-837262140819.
=============================================================

Seeing lost of crashes in AppleVA with unfortunately useless stacks. This is with media.fragmented-mp4.exposed true.
Do the missing symbols mean this isn't an official build? I assume from the build id this isn't the previous crash  we fixed.
This is with today's Nightly, though I've been hitting this crash for about a week.
Ok. Is there a url which repeatedly crashes, or is it intermittant?
It's intermittent and with multiple URLs. Next time I hit one I'll try to remember to get the URL that triggered it.
How frustrating. Something on this page triggers loading the decoder frameworks, but I don't see any playback calls.
Video finally loaded. Does it crash if you open http://v.theonion.com/onionmedia/videos/videometa/2102/zen_mp4_preview.mp4 directly?
(In reply to Ralph Giles (:rillian) from comment #7)
> Video finally loaded. Does it crash if you open
> http://v.theonion.com/onionmedia/videos/videometa/2102/zen_mp4_preview.mp4
> directly?

Nope :(
Hit the same problem again at avclub (http://www.avclub.com/article/what-game-has-truly-terrified-you-208457?utm_source=Facebook&utm_medium=SocialMarketing&utm_campaign=LinkPreview:1:Default) after a long delay with the page loaded. Interestingly the first time I loaded it also crashed with bp-bfbe4f69-ab56-4011-9a20-600922140828. I don't know if that is related.
I remain unenlightened. Do you crash with just the youtube link? You'll have to spoof the referrer because vevo. https://www.youtube.com/embed/LDZX4ooRsWs
tried this again.

at first launch with new profile, it did not crash, but as soon as the gmp-gmpopenh264 plugin has been installed, it seems to crash.

could this be the case? do we even need the openh264 encoder in this case?

terminal-output:

1409259637160	GMPInstallManager.onLoadXML	INFO	request completed downloading document
1409259637161	GMPInstallManager.onLoadXML	INFO	allowNonBuiltIn: false
1409259637173	GMPInstallManager.simpleCheckAndInstall	INFO	Found 1 addons advertised.
1409259637173	GMPInstallManager.simpleCheckAndInstall	INFO	Found addon: gmp-gmpopenh264 (isValid: true, isInstalled: false, isOpenH264: true, hashFunction: SHA512, hashValue: 0eac05de3b9dd939ece57450bcddf6fee04415a99744a0ce46ddb19c1205cbaf4d8c5a7b5efc2158c9fb257a7948024ed1604890b56382513922107e22273165, size: 282746)
1409259638434	GMPInstallManager.simpleCheckAndInstall	INFO	Addon installed successfully: gmp-gmpopenh264 (isValid: true, isInstalled: true, isOpenH264: true, hashFunction: SHA512, hashValue: 0eac05de3b9dd939ece57450bcddf6fee04415a99744a0ce46ddb19c1205cbaf4d8c5a7b5efc2158c9fb257a7948024ed1604890b56382513922107e22273165, size: 282746)
2014-08-28 23:01:11.408 plugin-container[33977:303] CoreText performance note: Client called CTFontCreateWithName() using name "Times Roman" and got font with PostScript name "Times-Roman". For best performance, only use PostScript names when calling this API.
2014-08-28 23:01:11.591 plugin-container[33977:303] CoreText performance note: Client called CTFontCreateWithName() using name "Arial" and got font with PostScript name "ArialMT". For best performance, only use PostScript names when calling this API.
2014-08-28 23:01:12.687 crashreporter[33991:303] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to /var/folders/4k/9fkbgrnn2hq11rrxtw_xfl380000gp/T/org.mozilla.crashreporter.savedState
[33977] ###!!! ABORT: Aborting on channel error.: file /builds/slave/m-cen-osx64-ntly-0000000000000/build/ipc/glue/MessageChannel.cpp, line 1618
[33977] ###!!! ABORT: Aborting on channel error.: file /builds/slave/m-cen-osx64-ntly-0000000000000/build/ipc/glue/MessageChannel.cpp, line 1618
I got the crash in the link on comment 9 when I clicked on the first YouTube video I saw.  This is on my machine with hardware acceleration disabled in the browser, because the GPU is completely toast.  HWA being disabled has been key to some issues in the past on this particular computer...
I have some software on my Mac called gfxCardStatus that lets you prefer the integrated graphics.  Normally, when I'm using the browser, if I started with it set to "integrated only" with HWA disabled, it stays that way, but when I clicked on the link in comment 7, it flipped immediately to "discrete only" which suggests that video playback tried to use my GPU despite HWA being disabled, which probably failed because my GPU is in some kind of burned out state.
Oh, maybe useful info: I use a monitor connected to the HDMI port on my Caldigit thunderbolt docking station.
For what it's worth, AppleVA is a "private framework" (it's in /System/Library/PrivateFrameworks/).  From running "strings" on it, I'd say it's involved in video and audio encoding and decoding.
Another thing to note:  All these crashes happen on secondary threads.
Crash Signature: [@ AppleVA@0x41b44] → [@ AppleVA@0x41b44 ] [@ AppleVA@0x456c3 ] [@ libsystem_platform.dylib@0x4f4b ] [@ libsystem_platform.dylib@0x5d47 ]
Together, these are easily the #1 Mac topcrasher.
Keywords: topcrash-mac
Summary: crash in AppleVA@0x41b44 → Crashes in AppleVA private framework
> Together, these are easily the #1 Mac topcrasher.

On the 34 branch.
It'd be nice if someone could get a gdb/lldb all-thread stack trace of these crashes.
Did it!

I got this visiting https://www.jottacloud.com/ and waiting a few seconds.
(Following up comment #22)

Forgot to mention that this was on OS X 10.9.4, testing with today's m-c nightly (vanilla settings).
Summary: Crashes in AppleVA private framework → Crashes in AppleVA private framework in mozilla::AppleVTDecoder::InitializeSession()
Yet another thing I forgot to mention:

My crash from comment #22 was on a Retina MacBook Pro with no attached hardware (using only the built-in display).
For me these crashes are 100% reproducible visiting https://www.jottacloud.com/ and waiting a few seconds (on OS X 10.9.4 with today's m-c nightly on my Retina MacBook Pro, with a "very clean" profile).

But they don't happen if I disable jemalloc by running FF as follows from a Terminal prompt:
NO_MAC_JEMALLOC=1 /path/to/FirefoxNightly.app/Contents/MacOS/firefox

They also don't happen with my Mac ASan build (ASan builds don't use jemalloc):
http://people.mozilla.org/~stmichaud/bmo/firefox-asan.dmg

Something similar has shown up at bug 1059486.  Those crashes are pretty clearly a use-after-free bug (probably Apple's).  So, ultimately, are these (I suspect) -- though this bug's crashes aren't at a memory-poisoned address.

So why do these crashes only happen when we're using jemalloc?  I have a couple hunches, which I've mentioned at bug 1059486.  And I've needinfoed Mike Hommey there.  I'll do it here, also.

By a "very clean" profile I mean one that's created by FF after deleting the following directories:

~/Library/Application Support/Firefox
~/Library/Application Support/Mozilla
~/Library/Caches/Firefox
Flags: needinfo?(mh+mozilla)
> By a "very clean" profile I mean one that's created by FF after deleting the following directories:
>
> ~/Library/Application Support/Firefox
> ~/Library/Application Support/Mozilla
> ~/Library/Caches/Firefox

Actually you can keep the crashes happening at https://www.jottacloud.com/ by deleting only the following directory.  (First quit FF, of course.  Then restart it.)

~/Library/Caches/Firefox
I hit this crash with any MP4 file, the first time it loads I just get the audio controls (As if the video track doesn't exist), on a reload I get a crash with the same stack as posted before.
Attached file AppleVA stack.txt
Sorry for this, but I just tried a video again and got the same crash in a different function. Not sure if it actually helps though.

I'm running Yosemite DP6 on a Early 2009 Mac Mini.
I think I might be experience this bug on 10.9.4. Whenever I try to go to youtube or vimeo page I get an automatic crash.
Crashed on http://c9.io/ twice in a row.
We don't need any more me-too reports of these crashes.

We also already have steps-to-reproduce (using https://www.jottacloud.com/):

1) Before running FirefoxNightly, delete the following directory and its contents:

~/Library/Caches/Firefox

2) Make sure you're testing with a mozilla-central nightly that contains the patch for bug 941926.

3) Run FirefoxNightly and set media.fragmented-mp4.exposed to true in about:config (if it isn't already set).

4) Visit https://www.jottacloud.com/ and wait 10-15 seconds.  You should crash.
Keywords: reproducible
Whiteboard: {STR in comment #32]
Blocks: 941296
No longer blocks: 941926
(Following up comment #32)

As best I can tell, these crashes only happen on OS X 10.9 and up.
Summary: Crashes in AppleVA private framework in mozilla::AppleVTDecoder::InitializeSession() → Crashes in AppleVA private framework in mozilla::AppleVTDecoder::InitializeSession() on OS X 10.9 and up
Whiteboard: {STR in comment #32] → [STR in comment #32]
Crash Signature: [@ AppleVA@0x41b44 ] [@ AppleVA@0x456c3 ] [@ libsystem_platform.dylib@0x4f4b ] [@ libsystem_platform.dylib@0x5d47 ] → [@ AppleVA@0x41b44 ] [@ AppleVA@0x456c3 ] [@ libsystem_platform.dylib@0x4f40 ] [@ libsystem_platform.dylib@0x4f4b ] [@ libsystem_platform.dylib@0x5d47 ] [@ libsystem_platform.dylib@0x5d4b ]
The total number of this bug's crashes (on the 34 branch) is about 20 times that of the #2 Mac topcrasher (on the 34 branch).

Somebody in Video/Audio really needs to step up here :-)
Thanks for the STR. They work for me on my loaner air with 10.10.

It's something about loading a bunch of video elements at once. https://www.jottacloud.com/ crashes reliably. Loading the individual videos doesn't crash. Loading several in successive tabs sometimes crashes.

I wonder if VTDecompressionSessionCreate() isn't thread-safe.
This works around the problem for me.
Assignee: nobody → giles
Attachment #8482948 - Flags: review?(ajones)
[Tracking Requested - why for this release]:
See comment #34, this is by far the Mac top crash in 34 at this time.
Attached patch Use an immutable dict (obsolete) — Splinter Review
Passing the flag to enable hardware acceleration in an immutable dict seems to work around the problem either. I don't understand enough about jemalloc interactions to say if this _should_ fix it, but maybe it finds a different path in the Apple code.

Jean-Yves, please sanity check my dict creation here. kCFBooleanTrue is a CFBooleanRef, so passing it like this should be safe? And thanks for the immutable idea. :)
Attachment #8483016 - Flags: review?(ajones)
Attachment #8483016 - Flags: feedback?(jyavenard)
Attachment #8482948 - Flags: review?(ajones) → review+
> Passing the flag to enable hardware acceleration in an immutable dict seems to work
> around the problem, too

Very interesting.  I wonder if the contents of immutable dictionaries are stored in a different kind of memory "zone" than the contents of mutable dictionaries?
I also wonder if, maybe, jemalloc doesn't get along with AutoCFRelease.

Could you try using a mutable dictionary, but without AutoCFRelease, and see if that makes a difference?
Comment on attachment 8483016 [details] [diff] [review]
Use an immutable dict

Per irc discussion, transferring techinical review to jya.
Attachment #8483016 - Flags: review?(jyavenard)
Attachment #8483016 - Flags: review?(ajones)
Attachment #8483016 - Flags: feedback?(jyavenard)
(In reply to Steven Michaud from comment #40)

> Could you try using a mutable dictionary, but without AutoCFRelease, and see
> if that makes a difference?

If I remove AutoCFRelease from the spec dictionary or the string key, I get a bus error. Even though I'm just letting them leak. Curiouser and curiouser.
Went ahead and landed the disable-acceleration workaround to make sure we get something into the next m-c merge. Will follow up with the second patch after review.
I wonder if it's jemalloc that has threading problems.
Duplicate of this bug: 1049269
Comment on attachment 8483016 [details] [diff] [review]
Use an immutable dict

Review of attachment 8483016 [details] [diff] [review]:
-----------------------------------------------------------------

All core foundation functions or objects require to use core foundation objects.

::: content/media/fmp4/apple/AppleVTDecoder.cpp
@@ +445,5 @@
>    }
>  
>    // Contruct video decoder selection spec.
> +  const void* specKeys[] = { "EnableHardwareAcceleratedVideoDecoder" };
> +  const void* specValues[] = { kCFBooleanTrue };

That will not work, the void* in specKeys really is a CFTypeRef.

That would be identical to not defining the kEnableHardwareAcceleratedVideoDecoderKey.

What about simply attempt to dlsym kVTVideoDecoderSpecification_EnableHardwareAcceleratedVideoDecoder, and if null not use it at all ?
Attachment #8483016 - Flags: review?(jyavenard) → review-
(In reply to Jean-Yves Avenard [:jya] from comment #47)

> That will not work, the void* in specKeys really is a CFTypeRef.

The problem is the key needs to be an CFStringRef?
(In reply to Ralph Giles (:rillian) from comment #48)
> (In reply to Jean-Yves Avenard [:jya] from comment #47)
> 
> > That will not work, the void* in specKeys really is a CFTypeRef.
> 
> The problem is the key needs to be an CFStringRef?

The key itslef according to the doc can be anything.

But my guess is that the VT is expecting a CFString, the way you lookup in your dictionary for a particular key is something like
[dict valueForKey:kVTVideoDecoderSpecification_EnableHardwareAcceleratedVideoDecoder];

which if the key is now a const char* is going to return nil.
Ok. I think my immutable idea was bogus then. The earlier patch was just failing to enable hardware acceleration. If I wrap it in CFSTR (which leaks) I get the same crash.

Back to jemalloc + hardware acceleration setup racing.
Attachment #8483016 - Attachment is obsolete: true
Comment on attachment 8482948 [details] [diff] [review]
Disable hardware acceleration

I'm out of brain for today. Will continue to look for a fix with hw acceleration enabled tomorrow.
Attachment #8482948 - Flags: checkin+
I got another crash (I can know reproduce it 100% of the time)

(lldb) bt
* thread #1: tid = 0x2618d, 0x0000000106657cad XUL`js::gc::ChunkBitmap::markIfUnmarked(this=0x000000011c600000, cell=0x0000000106cd90e9, color=32767) + 13 at Heap.h:740, queue = 'com.apple.main-thread', stop reason = signal SIGPIPE
  * frame #0: 0x0000000106657cad XUL`js::gc::ChunkBitmap::markIfUnmarked(this=0x000000011c600000, cell=0x0000000106cd90e9, color=32767) + 13 at Heap.h:740
    frame #1: 0x00000001066036ae XUL`js::gc::Cell::markIfUnmarked(this=0x000000011c6eecb8, color=0) const + 158 at Heap.h:1110
    frame #2: 0x0000000106574cbe XUL`PushMarkStack(gcmarker=0x00000001155b2d08, str=0x000000011c6eecb8) + 222 at Marking.cpp:1296
    frame #3: 0x000000010655a96b XUL`void MarkInternal<JSString>(trc=0x00000001155b2d08, thingp=0x00007fff5fbf4098) + 379 at Marking.cpp:303
    frame #4: 0x000000010659e76e XUL`void js::gc::MarkUnbarriered<JSString>(trc=0x00000001155b2d08, thingp=0x00007fff5fbf4098, name=0x00000001080f50ae) + 46 at Marking.cpp:326
    frame #5: 0x00000001065bc4d0 XUL`js::gc::BarrieredCell<JSString>::readBarrier(thing=0x000000011c6eecb8) + 368 at Barrier.h:270
    frame #6: 0x000000010659d640 XUL`JSString::readBarrier(thing=0x000000011c6eecb8) + 48 at String.h:500
    frame #7: 0x00000001063df0f5 XUL`js::AtomStateEntry::asPtr(this=0x00000001271d2cd8) const + 149 at jsatominlines.h:25
    frame #8: 0x00000001063e08a9 XUL`js::AtomHasher::match(entry=0x00000001271d2cd8, lookup=0x00007fff5fbf4350) + 25 at jsatominlines.h:164
    frame #9: 0x00000001063e074d XUL`js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::match(e=0x00000001271d2cd0, l=0x00007fff5fbf4350) + 45 at HashTable.h:1215
    frame #10: 0x00000001063e064e XUL`js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookup(this=0x00000001155de290, l=0x00007fff5fbf4350, keyHash=3132060656, collisionBit=1) const + 910 at HashTable.h:1265
    frame #11: 0x00000001063e2d4a XUL`js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookupForAdd(this=0x00000001155de290, l=0x00007fff5fbf4350) const + 106 at HashTable.h:1557
    frame #12: 0x00000001063e2984 XUL`js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::lookupForAdd(this=0x00000001155de290, l=0x00007fff5fbf4350) const + 36 at HashTable.h:372
    frame #13: 0x00000001063dcd8d XUL`JSAtom* AtomizeAndCopyChars<unsigned char>(cx=0x0000000100393540, tbchars=0x0000000107e4a0e4, length=14, ib=DoNotInternAtom) + 317 at jsatom.cpp:331
    frame #14: 0x00000001063dbea2 XUL`js::Atomize(cx=0x0000000100393540, bytes=0x0000000107e4a0e4, length=14, ib=DoNotInternAtom) + 114 at jsatom.cpp:430
    frame #15: 0x00000001069ae31c XUL`DefineProperty(cx=0x0000000100393540, obj=JS::HandleObject at 0x00007fff5fbf4560, name=0x0000000107e4a0e4, value=JS::HandleValue at 0x00007fff5fbf4550, getter=0x0000000109561cd0, setter=0x0000000109561ce0, attrs=73, flags=0) + 396 at jsapi.cpp:3007
    frame #16: 0x00000001069af909 XUL`JS_DefineProperties(cx=0x0000000100393540, obj=JS::HandleObject at 0x00007fff5fbf4610, ps=0x0000000109561cc0) + 441 at jsapi.cpp:3257
    frame #17: 0x00000001038215cd XUL`mozilla::dom::Define(cx=0x0000000100393540, obj=Handle<JSObject *> at 0x00007fff5fbf4640, spec=0x0000000109561cc0) + 45 at BindingUtils.cpp:300
    frame #18: 0x0000000103823f50 XUL`bool mozilla::dom::DefinePrefable<JSPropertySpec const>(cx=0x0000000100393540, obj=Handle<JSObject *> at 0x00007fff5fbf4688, props=0x0000000109908cd0) + 304 at BindingUtils.cpp:317
    frame #19: 0x0000000103810b85 XUL`mozilla::dom::DefineProperties(cx=0x0000000100393540, obj=Handle<JSObject *> at 0x00007fff5fbf46f8, properties=0x0000000109554208, chromeOnlyProperties=0x0000000000000000) + 149 at BindingUtils.cpp:621
    frame #20: 0x0000000103811678 XUL`mozilla::dom::CreateInterfacePrototypeObject(cx=0x0000000100393540, global=Handle<JSObject *> at 0x00007fff5fbf47a8, parentProto=Handle<JSObject *> at 0x00007fff5fbf47a0, protoClass=0x0000000109554600, properties=0x0000000109554208, chromeOnlyProperties=0x0000000000000000) + 216 at BindingUtils.cpp:602
    frame #21: 0x00000001038112c6 XUL`mozilla::dom::CreateInterfaceObjects(cx=0x0000000100393540, global=Handle<JSObject *> at 0x00007fff5fbf4958, protoProto=Handle<JSObject *> at 0x00007fff5fbf4950, protoClass=0x0000000109554600, protoCache=0x0000000134543100, constructorProto=Handle<JSObject *> at 0x00007fff5fbf4938, constructorClass=0x0000000109554790, constructor=0x0000000000000000, ctorNargs=0, namedConstructors=0x0000000000000000, constructorCache=0x00000001345445a8, properties=0x0000000109554208, chromeOnlyProperties=0x0000000000000000, name=0x0000000107e4551c, defineOnGlobal=true) + 1526 at BindingUtils.cpp:691
    frame #22: 0x0000000102e5cf1d XUL`mozilla::dom::CSS2PropertiesBinding::CreateInterfaceObjects(aCx=0x0000000100393540, aGlobal=Handle<JSObject *> at 0x00007fff5fbf4ba0, aProtoAndIfaceCache=0x000000011f705a90, aDefineOnGlobal=true) + 1597 at CSS2PropertiesBinding.cpp:21385
    frame #23: 0x0000000102e5c221 XUL`mozilla::dom::CSS2PropertiesBinding::GetProtoObject(aCx=0x0000000100393540, aGlobal=Handle<JSObject *> at 0x00007fff5fbf4bf8) + 161 at CSS2PropertiesBinding.cpp:21409
    frame #24: 0x0000000102e5c5bc XUL`mozilla::dom::CSS2PropertiesBinding::Wrap(aCx=0x0000000100393540, aObject=0x00000001345c8580, aCache=0x00000001345c8588) + 860 at CSS2PropertiesBinding.cpp:21317
    frame #25: 0x000000010496a935 XUL`JSObject* mozilla::dom::CSS2PropertiesBinding::Wrap<nsDOMCSSDeclaration>(aCx=0x0000000100393540, aObject=0x00000001345c8580) + 101 at CSS2PropertiesBinding.h:49
    frame #26: 0x000000010493539d XUL`nsDOMCSSDeclaration::WrapObject(this=0x00000001345c8580, aCx=0x0000000100393540) + 29 at nsDOMCSSDeclaration.cpp:31
    frame #27: 0x00000001049353df XUL`non-virtual thunk to nsDOMCSSDeclaration::WrapObject(this=0x00000001345c8588, aCx=0x0000000100393540) + 47 at Unified_cpp_layout_style1.cpp:32
    frame #28: 0x0000000103162954 XUL`bool mozilla::dom::WrapNewBindingObject<nsICSSDeclaration>(cx=0x0000000100393540, value=0x00000001345c8580, rval=MutableHandle<JS::Value> at 0x00007fff5fbf4ed0) + 276 at BindingUtils.h:862
    frame #29: 0x0000000103162834 XUL`bool mozilla::dom::WrapNewBindingObject<nsICSSDeclaration*>(cx=0x0000000100393540, scope=Handle<JSObject *> at 0x00007fff5fbf4f20, value=0x00007fff5fbf4f60, rval=MutableHandle<JS::Value> at 0x00007fff5fbf4f10) + 52 at BindingUtils.h:1602
    frame #30: 0x00000001037692b6 XUL`mozilla::dom::XULElementBinding::get_style(cx=0x0000000100393540, obj=Handle<JSObject *> at 0x00007fff5fbf4f78, self=0x000000012f5181a0, args=JSJitGetterCallArgs at 0x00007fff5fbf4f68) + 182 at XULElementBinding.cpp:2098
    frame #31: 0x00000001038191e9 XUL`mozilla::dom::GenericBindingGetter(cx=0x0000000100393540, argc=0, vp=0x00007fff5fbf57a0) + 665 at BindingUtils.cpp:2414
    frame #32: 0x0000000106cb0235 XUL`js::CallJSNative(cx=0x0000000100393540, native=0x0000000103818f50, args=0x00007fff5fbf5670)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) + 165 at jscntxtinlines.h:231
    frame #33: 0x0000000106c84311 XUL`js::Invoke(cx=0x0000000100393540, args=<unavailable>, construct=NO_CONSTRUCT) + 1217 at Interpreter.cpp:481
    frame #34: 0x0000000106c84c62 XUL`js::Invoke(cx=0x0000000100393540, thisv=0x00007fff5fbf5858, fval=0x00007fff5fbf5880, argc=0, argv=0x0000000000000000, rval=JS::MutableHandleValue at 0x00007fff5fbf57f0) + 834 at Interpreter.cpp:537
    frame #35: 0x0000000106c85666 XUL`js::InvokeGetterOrSetter(cx=0x0000000100393540, obj=0x000000012ede57c0, fval=Value at 0x00007fff5fbf5880, argc=0, argv=0x0000000000000000, rval=JS::MutableHandleValue at 0x00007fff5fbf5868) + 150 at Interpreter.cpp:609
    frame #36: 0x0000000106b7c6d0 XUL`js::Shape::get(this=0x000000012f9d9fd8, cx=0x0000000100393540, receiver=JS::HandleObject at 0x00007fff5fbf5960, obj=0x000000012ede57c0, pobj=0x000000012edec7a0, vp=JS::MutableHandleValue at 0x00007fff5fbf5948) + 256 at Shape-inl.h:46
    frame #37: 0x0000000106aa243b XUL`bool NativeGetInline<(cx=0x0000000100393540, obj=js::MaybeRooted<JSObject *>::HandleType at 0x00007fff5fbf5a88, receiver=js::MaybeRooted<JSObject *>::HandleType at 0x00007fff5fbf5a80, pobj=js::MaybeRooted<JSObject *>::HandleType at 0x00007fff5fbf5a78, shape=js::MaybeRooted<js::Shape *>::HandleType at 0x00007fff5fbf5a70, vp=js::MaybeRooted<JS::Value>::MutableHandleType at 0x00007fff5fbf5a68)1>(JSContext*, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<js::Shape*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JS::Value, (js::AllowGC)1>::MutableHandleType) + 1083 at jsobj.cpp:4852
    frame #38: 0x0000000106aa2f24 XUL`bool GetPropertyHelperInline<(cx=0x0000000100393540, obj=js::MaybeRooted<JSObject *>::HandleType at 0x00007fff5fbf5d88, receiver=js::MaybeRooted<JSObject *>::HandleType at 0x00007fff5fbf5d80, id=js::MaybeRooted<jsid>::HandleType at 0x00007fff5fbf5d78, vp=js::MaybeRooted<JS::Value>::MutableHandleType at 0x00007fff5fbf5d70)1>(JSContext*, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<JSObject*, (js::AllowGC)1>::HandleType, js::MaybeRooted<jsid, (js::AllowGC)1>::HandleType, js::MaybeRooted<JS::Value, (js::AllowGC)1>::MutableHandleType) + 2388 at jsobj.cpp:5047
    frame #39: 0x0000000106aa25c5 XUL`js::baseops::GetProperty(cx=0x0000000100393540, obj=JS::HandleObject at 0x00007fff5fbf5df0, receiver=JS::HandleObject at 0x00007fff5fbf5de8, id=JS::HandleId at 0x00007fff5fbf5de0, vp=JS::MutableHandleValue at 0x00007fff5fbf5dd8) + 85 at jsobj.cpp:5057
    frame #40: 0x0000000106cf8d5e XUL`JSObject::getGeneric(cx=0x0000000100393540, obj=JS::HandleObject at 0x00007fff5fbf5e78, receiver=JS::HandleObject at 0x00007fff5fbf5e70, id=JS::HandleId at 0x00007fff5fbf5e68, vp=JS::MutableHandleValue at 0x00007fff5fbf5e60) + 382 at jsobj.h:1023
    frame #41: 0x0000000106abc3e9 XUL`js::DirectProxyHandler::get(this=0x000000010986fbc8, cx=0x0000000100393540, proxy=JS::HandleObject at 0x00007fff5fbf5f48, receiver=JS::HandleObject at 0x00007fff5fbf5f40, id=JS::HandleId at 0x00007fff5fbf5f38, vp=JS::MutableHandleValue at 0x00007fff5fbf5f30) const + 281 at jsproxy.cpp:608
    frame #42: 0x0000000106bccec3 XUL`js::CrossCompartmentWrapper::get(this=0x000000010986fbc8, cx=0x0000000100393540, wrapper=JS::HandleObject at 0x00007fff5fbf6070, receiver=JS::HandleObject at 0x00007fff5fbf6068, id=JS::HandleId at 0x00007fff5fbf6060, vp=JS::MutableHandleValue at 0x00007fff5fbf6058) const + 403 at jswrapper.cpp:299
    frame #43: 0x0000000106ac4654 XUL`js::Proxy::get(cx=0x0000000100393540, proxy=JS::HandleObject at 0x00007fff5fbf6208, receiver=JS::HandleObject at 0x00007fff5fbf6200, id=JS::HandleId at 0x00007fff5fbf61f8, vp=JS::MutableHandleValue at 0x00007fff5fbf61f0) + 548 at jsproxy.cpp:2376
    frame #44: 0x0000000106ac6845 XUL`js::proxy_GetGeneric(cx=0x0000000100393540, obj=JS::HandleObject at 0x00007fff5fbf6270, receiver=JS::HandleObject at 0x00007fff5fbf6268, id=JS::HandleId at 0x00007fff5fbf6260, vp=JS::MutableHandleValue at 0x00007fff5fbf6258) + 85 at jsproxy.cpp:2739
    frame #45: 0x0000000106cf8d0f XUL`JSObject::getGeneric(cx=0x0000000100393540, obj=JS::HandleObject at 0x00007fff5fbf62f8, receiver=JS::HandleObject at 0x00007fff5fbf62f0, id=JS::HandleId at 0x00007fff5fbf62e8, vp=JS::MutableHandleValue at 0x00007fff5fbf62e0) + 303 at jsobj.h:1020
    frame #46: 0x0000000106ca87f7 XUL`GetPropertyOperation(cx=0x0000000100393540, fp=0x00000001175910c8, script=JS::HandleScript at 0x00007fff5fbf64d0, pc=0x0000000119dccfda, lval=JS::MutableHandleValue at 0x00007fff5fbf64c0, vp=JS::MutableHandleValue at 0x00007fff5fbf64b8) + 1239 at Interpreter.cpp:251
    frame #47: 0x0000000106c783dd XUL`Interpret(cx=0x0000000100393540, state=0x00007fff5fbf93b8) + 45965 at Interpreter.cpp:2397
    frame #48: 0x0000000106c6cf1b XUL`js::RunScript(cx=0x0000000100393540, state=0x00007fff5fbf93b8) + 667 at Interpreter.cpp:428
    frame #49: 0x0000000106c84431 XUL`js::Invoke(cx=0x0000000100393540, args=<unavailable>, construct=NO_CONSTRUCT) + 1505 at Interpreter.cpp:500
    frame #50: 0x0000000106a4f3ce XUL`js_fun_call(cx=0x0000000100393540, argc=2, vp=0x00007fff5fbf9c60) + 574 at jsfun.cpp:1253
    frame #51: 0x0000000106cb0235 XUL`js::CallJSNative(cx=0x0000000100393540, native=0x0000000106a4f190, args=0x00007fff5fbf9b30)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) + 165 at jscntxtinlines.h:231
    frame #52: 0x0000000106c84311 XUL`js::Invoke(cx=0x0000000100393540, args=<unavailable>, construct=NO_CONSTRUCT) + 1217 at Interpreter.cpp:481
    frame #53: 0x0000000106c84c62 XUL`js::Invoke(cx=0x0000000100393540, thisv=0x00007fff5fbfa788, fval=0x00007fff5fbf9d78, argc=2, argv=0x00007fff5fbfa790, rval=JS::MutableHandleValue at 0x00007fff5fbf9cb0) + 834 at Interpreter.cpp:537
    frame #54: 0x0000000106abb55c XUL`js::DirectProxyHandler::call(this=0x000000010986fbc8, cx=0x0000000100393540, proxy=JS::HandleObject at 0x00007fff5fbf9d98, args=0x00007fff5fbfa050) const + 316 at jsproxy.cpp:478
    frame #55: 0x0000000106bcdd1e XUL`js::CrossCompartmentWrapper::call(this=0x000000010986fbc8, cx=0x0000000100393540, wrapper=JS::HandleObject at 0x00007fff5fbf9ed0, args=0x00007fff5fbfa050) const + 574 at jswrapper.cpp:431
    frame #56: 0x0000000106ac5301 XUL`js::Proxy::call(cx=0x0000000100393540, proxy=JS::HandleObject at 0x00007fff5fbf9fc8, args=0x00007fff5fbfa050) + 385 at jsproxy.cpp:2507
    frame #57: 0x0000000106ac774a XUL`js::proxy_Call(cx=0x0000000100393540, argc=2, vp=0x00007fff5fbfa780) + 250 at jsproxy.cpp:2909
    frame #58: 0x0000000106cb0235 XUL`js::CallJSNative(cx=0x0000000100393540, native=0x0000000106ac7650, args=0x00007fff5fbfa650)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) + 165 at jscntxtinlines.h:231
    frame #59: 0x0000000106c8422e XUL`js::Invoke(cx=0x0000000100393540, args=<unavailable>, construct=NO_CONSTRUCT) + 990 at Interpreter.cpp:474
    frame #60: 0x0000000106c84c62 XUL`js::Invoke(cx=0x0000000100393540, thisv=0x00007fff5fbfaa10, fval=0x00007fff5fbfaa40, argc=2, argv=0x00007fff5fbfab98, rval=JS::MutableHandleValue at 0x00007fff5fbfa7d0) + 834 at Interpreter.cpp:537
    frame #61: 0x0000000106690519 XUL`js::jit::DoCallFallback(cx=0x0000000100393540, frame=0x00007fff5fbfac00, stub_=0x000000011d781320, argc=2, vp=0x00007fff5fbfab88, res=JS::MutableHandleValue at 0x00007fff5fbfaad0) + 2041 at BaselineIC.cpp:8414
(lldb) 

the jemalloc stuff is definitely in the way.
njn suggested that the issue could be that the allocator is done by one method, and the release by another...
I added a breakpoint on the value of spec.
And twice now (over a dozen runs), the spec dictionary appeared as empty right after the call to VTDecompressionDessionCreate.

It's as if the variable was freed. Seeing that the gc is involved, could it be that it is somehow not marked as being used and is being garbage collected half-way through?
Nightly stops crashing for now on YouTube, but playlists doesn't skip to the next video automatically anymore.
(In reply to comment #52)

> I got another crash (I can now reproduce it 100% of the time)

What are your steps to reproduce?

And next time please make your stack an all-thread stack, and attach it rather than pasting it into a comment.
Comment on attachment 8482948 [details] [diff] [review]
Disable hardware acceleration

Approval Request Comment
[Feature/regressing bug #]: 941296

[User impact if declined]:

This was a top-crash bug for mac over the weekend. Users will experience crashes visiting sites with embedded videos. The alternative is to disable mp4 video playback entirely, which is a high-profile feature.

[Describe test coverage new/current, TBPL]:

Green on inbound. We don't have test coverage for the issue.

[Risks and why]: 

Risk is low. The patch removes an optional parameter when initializing a video decoder.

[String/UUID change made/needed]: None
Attachment #8482948 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/3e85e1a1d840
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Blocks: 1062596
I'm out of ideas; we'll go without asking for hardware acceleration for now, since that works fine on desktops. I opened bug 1062596 for discussing a re-enable fix.
Duplicate of this bug: 1061171
Turns out bug 1059486 isn't related -- that bug is a very simple use-after-free, and happens with or without jemalloc (unlike I first thought).  In fact Apple has fixed it in Yosemite DP7.
See Also: 1059486
Turns out this bug was caused by running out of stack space.  See bug 1062596 comment #3.

And at least some of the time, this bug's crashes also happen with jemalloc off.

So it looks like there's no solid connection to jemalloc here, either.
Flags: needinfo?(mh+mozilla)
Duplicate of this bug: 1064078
Comment on attachment 8482948 [details] [diff] [review]
Disable hardware acceleration

Aurora+
Attachment #8482948 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
sjw, Are you still seeing the issue with playlists not moving to the next video that you mentioned in Comment 54?  If so, can you report that in a new bug?  Thanks!
Flags: needinfo?(sjw)
(In reply to Liz Henry :lizzard from comment #64)
> sjw, Are you still seeing the issue with playlists not moving to the next
> video that you mentioned in Comment 54?  If so, can you report that in a new
> bug?  Thanks!

I was not able to reproduce in safe mode.
Flags: needinfo?(sjw)
Thanks for confirming.
You need to log in before you can comment on or make changes to this bug.