1246743 - turn -stdlib=libc++ on for mac builds where appropriate

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Nathan Froyd [:froydnj]]

We have the technology.

Comment 1

[Nathan Froyd [:froydnj]]

Attachment: part 1 - build script for libcxx

This patch adds a build script for the libc++.a file we're going to use
for OS X builds in subsequent patches for this bug.  The build script is
adapted from the one Chromium uses.

Comment 2

[Nathan Froyd [:froydnj]]

Attachment: part 2 - manifest changes for static libc++.a for OS X builds

Comment 3

[Nathan Froyd [:froydnj]]

Attachment: part 3 - build system support for static libc++.a on OS X

It's worth pointing out that these changes break the TC tier-2 OSX-on-Linux
builds we have running.  Talking to Ted over IRC, he indicated that it would be
OK to break them, since we're not really sure if they want to be a thing or
not.  Explicitly flagging Ted to confirm his decision for posterity.

The current patches break the OSX-on-Linux builds in clang-plugin (I think this
is because the libc++.a we use is a fat archive), but there are also issues
with the header files in the 10.7 SDK we use.

Comment 4

[Nathan Froyd [:froydnj]]

Attachment: part 4 - add libc++ license to about:license when using it on OS X

Since we're now using libc++ on the Mac, but including it statically in the
binaries we distribute, we need to add license text for libc++.  Gerv for the
license bits, glandium for the build system parts.

Comment 5

[Nathan Froyd [:froydnj]]

The run below shows green builds and tests everywhere with the above patches, except for some mysterious timeouts for cppunittests on 10.6 opt (!).  I have no idea what's going on with that test.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3fbd325efe20

Ehsan, do you have any immediate insight into what's going on with that test?  I don't think the editor/ stuff goes anywhere near std::...  How doe you feel about just disabling that test? :D

Comment 6

[Mike Hommey [:glandium]]

Comment on attachment 8723905 [details] [diff] [review]
part 3 - build system support for static libc++.a on OS X

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

::: build/templates.mozbuild
@@ +26,5 @@
> +    elif CONFIG['OS_TARGET'] == 'Darwin' and CONFIG['MACOSX_DEPLOYMENT_TARGET'] == '10.6':
> +        OS_LIBS += [
> +            '-L' + TOPSRCDIR + '/config/external/libcxx',
> +            '-lc++',
> +        ]

This would feel less magic if you'd set an AC_SUBST (or even AC_SUBST_LIST) in old-configure.in and used it here. Plus, that would make the path set all in one place.

::: old-configure.in
@@ +455,5 @@
>  
> +case "$_MACOSX_DEPLOYMENT_TARGET" in
> +10.6)
> +    if ! test -f "$_topsrcdir/config/external/libcxx/libc++.a"; then
> +        AC_ERROR([compiling for OS X 10.6 requires a static libc++])

Any reason this is not together with the -stdlib=libc++ flag? Oh yeah, _MACOSX_DEPLOYMENT_TARGET. Then is there a reason not to set -stdlib=libc++ here?

Comment 7

[Mike Hommey [:glandium]]

Comment on attachment 8723906 [details] [diff] [review]
part 4 - add libc++ license to about:license when using it on OS X

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

r+ for the build part.

::: toolkit/content/license.html
@@ +3654,5 @@
> +    <p class="correctme">This license applies to the copy of libc++ built
> +    via <span class="path">build/build-libcxx/libcxx-build.sh</span>.</p>
> +
> +<pre>
> +Copyright (c) 2009-2014 by the contributors listed in CREDITS.TXT

where is CREDITS.TXT? is the question that comes to mind when reading this.

Comment 8

[Gervase Markham [:gerv]]

Comment on attachment 8723906 [details] [diff] [review]
part 4 - add libc++ license to about:license when using it on OS X

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

r=gerv.

Gerv

::: toolkit/content/license.html
@@ +3654,5 @@
> +    <p class="correctme">This license applies to the copy of libc++ built
> +    via <span class="path">build/build-libcxx/libcxx-build.sh</span>.</p>
> +
> +<pre>
> +Copyright (c) 2009-2014 by the contributors listed in CREDITS.TXT

This isn't a showstopper, but ideally, we would change this to give the path to the correct CREDITS.TXT in our source tree.

Comment 9

[(no longer active)]

(In reply to Nathan Froyd [:froydnj] from comment #5)
> The run below shows green builds and tests everywhere with the above
> patches, except for some mysterious timeouts for cppunittests on 10.6 opt
> (!).  I have no idea what's going on with that test.
> 
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=3fbd325efe20
> 
> Ehsan, do you have any immediate insight into what's going on with that
> test?  I don't think the editor/ stuff goes anywhere near std::...  How doe
> you feel about just disabling that test? :D

The reason why this test fails is that your changes somehow make it slower.  See for example bug 929985 where we had to adjust the number of iterations for Android and ASAN.  Perhaps we should dial down the 500 number somewhat.  Can you try playing with that please?

If you want to disable this test, I won't lose any sleep over it, but I think it's worth at least a shot to try to dial down the number of iterations first...

Comment 10

[Nathan Froyd [:froydnj]]

(In reply to Mike Hommey [:glandium] from comment #6)
> This would feel less magic if you'd set an AC_SUBST (or even AC_SUBST_LIST)
> in old-configure.in and used it here. Plus, that would make the path set all
> in one place.

That's a good point, I'll do that.

> ::: old-configure.in
> @@ +455,5 @@
> >  
> > +case "$_MACOSX_DEPLOYMENT_TARGET" in
> > +10.6)
> > +    if ! test -f "$_topsrcdir/config/external/libcxx/libc++.a"; then
> > +        AC_ERROR([compiling for OS X 10.6 requires a static libc++])
> 
> Any reason this is not together with the -stdlib=libc++ flag? Oh yeah,
> _MACOSX_DEPLOYMENT_TARGET. Then is there a reason not to set -stdlib=libc++
> here?

I think of -stdlibc++ as one of the default compilation options for Darwin, hence its location in compiler-opts.m4.  This bit right here is more of an implementation detail, IMHO.

Comment 11

[Nathan Froyd [:froydnj]]

(In reply to :Ehsan Akhgari from comment #9)
> The reason why this test fails is that your changes somehow make it slower. 
> See for example bug 929985 where we had to adjust the number of iterations
> for Android and ASAN.  Perhaps we should dial down the 500 number somewhat. 
> Can you try playing with that please?
> 
> If you want to disable this test, I won't lose any sleep over it, but I
> think it's worth at least a shot to try to dial down the number of
> iterations first...

We can do that, but it's also kind of odd that the test succeeds in DEBUG (where the whole test takes less than a second), but fails in opt...

Comment 12

[Nathan Froyd [:froydnj]]

(In reply to Gervase Markham [:gerv] from comment #8)
> ::: toolkit/content/license.html
> @@ +3654,5 @@
> > +    <p class="correctme">This license applies to the copy of libc++ built
> > +    via <span class="path">build/build-libcxx/libcxx-build.sh</span>.</p>
> > +
> > +<pre>
> > +Copyright (c) 2009-2014 by the contributors listed in CREDITS.TXT
> 
> This isn't a showstopper, but ideally, we would change this to give the path
> to the correct CREDITS.TXT in our source tree.

We don't have a copy of the libc++ source in the tree.  Does it suffice to simply copy the correct CREDITS.TXT into our source tree and refer to that?

Comment 13

[Gervase Markham [:gerv]]

Oh. Then just change to "the libc++ CREDITS.TXT".

Gerv

Comment 14

[Nathan Froyd [:froydnj]]

Attachment: part 3 - build system support for static libc++.a on OS X

Redone based on glandium's comments; after thinking about it some more, I moved
the -stdlib=libc++ option to old-configure.in, so that the comments about our
libc++ situation can all be in the same place.

Comment 15

[Michael Shal [:mshal]]

Comment on attachment 8723903 [details] [diff] [review]
part 1 - build script for libcxx

Any idea how hard it would be to get this working on our OSX build machine hardware? We seem to have some older versions of things - the first problem I ran into is that xcrun doesn't actually have a -show-sdk-path argument. I tried replacing that part of the script by hardcoding /Developer/SDKs/MacOSX10.7.sdk/, and then I hit:

+ cd libcxxbuild
+ mkdir libcxx
+ pushd libcxx
/var/folders/ly/7r7cl9tj5sg8c0j11hszlq2000000w/T/libcpp.kEZ9T9dy/libcxxbuild/libcxx /var/folders/ly/7r7cl9tj5sg8c0j11hszlq2000000w/T/libcpp.kEZ9T9dy/libcxxbuild ~/test-1246743
+ clang -c -I../../libcxx/include/ ../../libcxx/src/algorithm.cpp ../../libcxx/src/any.cpp ../../libcxx/src/bind.cpp ../../libcxx/src/chrono.cpp ../../libcxx/src/condition_variable.cpp ../../libcxx/src/debug.cpp ../../libcxx/src/exception.cpp ../../libcxx/src/future.cpp ../../libcxx/src/hash.cpp ../../libcxx/src/ios.cpp ../../libcxx/src/iostream.cpp ../../libcxx/src/locale.cpp ../../libcxx/src/memory.cpp ../../libcxx/src/mutex.cpp ../../libcxx/src/new.cpp ../../libcxx/src/optional.cpp ../../libcxx/src/random.cpp ../../libcxx/src/regex.cpp ../../libcxx/src/shared_mutex.cpp ../../libcxx/src/stdexcept.cpp ../../libcxx/src/string.cpp ../../libcxx/src/strstream.cpp ../../libcxx/src/system_error.cpp ../../libcxx/src/thread.cpp ../../libcxx/src/typeinfo.cpp ../../libcxx/src/utility.cpp ../../libcxx/src/valarray.cpp -nostdinc++ -O3 -std=c++11 -fstrict-aliasing -fvisibility=hidden -fvisibility-inlines-hidden -mmacosx-version-min=10.6 -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.7.sdk/
error: invalid value 'c++11' in '-std=c++11'

Comment 16

[Michael Shal [:mshal]]

Comment on attachment 8723903 [details] [diff] [review]
part 1 - build script for libcxx

We discussed a bit on IRC - the build gets a little further using the clang from tooltool (which is what we use in our OSX builds, rather than the outdated default on the builders), but it still runs into further errors regarding a visibility mismatch.

We could probably work around the xcrun -show-sdk-path by doing something like: $(xcrun -show-sdk-path || echo /Developer/SDKs/MacOSX10.7.sdk/)

Instead of solving those issues here, please file a followup bug.

Comment 17

[Mike Hommey [:glandium]]

Comment on attachment 8724094 [details] [diff] [review]
part 3 - build system support for static libc++.a on OS X

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

You'll want the same in js/src/old-configure.in. (Yeah, I can't wait to kill the dual-configure thing)

::: build/templates.mozbuild
@@ +24,5 @@
>          if CONFIG['MOZ_ANDROID_CXX_STL'] == 'mozstlport':
>              USE_LIBS += ['stlport']
> +    elif CONFIG['OS_TARGET'] == 'Darwin' and CONFIG['MACOSX_DEPLOYMENT_TARGET'] == '10.6':
> +        OS_LIBS += [
> +            '-L' + CONFIG['MOZ_MACOSX_LIBCXX_BINDIR'],

I was thinking about the whole "-L... -lc++" flags in a AC_SUBST_LIST in my previous comment. Sorry if that wasn't clear.

Comment 18

[(not currently active) Ted Mielczarek]

(In reply to Nathan Froyd [:froydnj] from comment #3)
> It's worth pointing out that these changes break the TC tier-2 OSX-on-Linux
> builds we have running.  Talking to Ted over IRC, he indicated that it would
> be
> OK to break them, since we're not really sure if they want to be a thing or
> not.  Explicitly flagging Ted to confirm his decision for posterity.

That's...a slight paraphrase. :) They are Tier-2, and it's OK to break them as long as you have a plan to fix them. You just don't have to block your work on fixing them at a first cut. We definitely want them to replace the existing mac builds long-term, but that's blocked on getting tests running on them at the very least.

Comment 19

[Nathan Froyd [:froydnj]]

I realized last week that there's a problem: the patches as they currently stand require a binary libc++ if you're targeting 10.6.  But all of our builds, not just our infrastructure ones, require 10.6.  That means local builds will break if these patches go in as-is.

I think the 10.7 SDK also will not work to compile Gecko, because the libc++ headers there are not good enough.  Maybe 10.8 won't work either; whatever we have on the builders obviously works with the built-in libc++ headers, but I'm not sure what version that is.

Setting up our automation configs to explicitly enable 10.6 and changing the default for non-automation builds seems like a reasonable way around this.  Do we have Mac SDK experts would be able to advise one way or the other or do I get to become an SDK expert?  Ted?

Comment 20

[(not currently active) Ted Mielczarek]

(In reply to Nathan Froyd [:froydnj] from comment #19)
> Setting up our automation configs to explicitly enable 10.6 and changing the
> default for non-automation builds seems like a reasonable way around this. 
> Do we have Mac SDK experts would be able to advise one way or the other or
> do I get to become an SDK expert?  Ted?

The downside to making automation defaults different from local defaults is twofold:
1) It's one more thing you have to change if you want to reproduce the builds we ship.
2) It increases the likelihood of a developer's local build not working in CI.

That being said, if it comes down to bumping the default version for non-automation builds or trying to figure out horrible workarounds, the former is preferable. One plausible way forward would be to tie the OS X target to `--enable-release`, and have separate "default release OS X target" and "default OS X target".

> I think the 10.7 SDK also will not work to compile Gecko, because the libc++
> headers there are not good enough.  Maybe 10.8 won't work either; whatever
> we have on the builders obviously works with the built-in libc++ headers,
> but I'm not sure what version that is.

Assuming our OS X builders (which run 10.7) are running the latest Xcode (4.6.x), they should have the 10.8 SDK installed, but you'd have to either borrow a builder or ask someone in RelEng to verify that for you.

Apparently we only specify an SDK for our Universal builds, which use the 10.7 SDK:
https://dxr.mozilla.org/mozilla-central/rev/05c087337043dd8e71cc27bdb5b9d55fd00aaa26/build/macosx/universal/mozconfig.common#15

...which means that our OS X debug builds are just using whatever the default SDK they have is. It's generally safe to use a newer SDK as long as we continue setting the MACOSX_DEPLOYMENT_TARGET to the minimum version we want to support--Apple explicitly supports this. If you can use the 10.8 SDK and our builders already have it then your life should be easy. If they don't have it then you'll need to get RelEng to install a copy on the builders, which is just copying files around so shouldn't be terribly hard. You can copy it off of a Mac with a newer Xcode installed or there exist scripts to extract an SDK from a downloaded Xcode package.

Comment 21

[(not currently active) Ted Mielczarek]

Comment on attachment 8724094 [details] [diff] [review]
part 3 - build system support for static libc++.a on OS X

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

This is OK, but let's wait and see if 10.6 support is being dropped before adding this.

Comment 22

[Nathan Froyd [:froydnj]]

What's the recommended way to add compiler flags based on configure options nowadays?  I see I can access --enable-macos-target, but I'm at a bit of a loss as to how to turn that into -stdlib=libc++.

Comment 23

[Mike Hommey [:glandium]]

Was the answer on irc enough? Or is the needinfo here still needed? If so, please re-flag me.

Comment 24

[Nathan Froyd [:froydnj]]

Attachment: use libc++ on OS X builds

Since we no longer have to support 10.6, we can just use libc++ everywhere.

This change does break cross-OS X builds:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=726751fba647

but given comment 18, I believe that's OK.  Fixing that breakage should be a
matter of figuring out what headers the native builds are using, and then
importing those headers into our cross 10.7 sysroot.

Comment 25

[Nathan Froyd [:froydnj]]

(In reply to Nathan Froyd [:froydnj] from comment #24)
> Since we no longer have to support 10.6, we can just use libc++ everywhere.

Since we're no longer linking to a static copy of libc++ and then shipping that, but instead relying on the copy of libc++ that ships with every Mac, I believe that changes to about:license are no longer required.  Gerv, is that correct?

Comment 26

[Gervase Markham [:gerv]]

(In reply to Nathan Froyd [:froydnj] from comment #25)
> Since we're no longer linking to a static copy of libc++ and then shipping
> that, but instead relying on the copy of libc++ that ships with every Mac, I
> believe that changes to about:license are no longer required.  Gerv, is that
> correct?

If it's not in our shipped package, its license doesn't need to be in about:license.

Gerv

Comment 27

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/66aec66b11b4

Comment 28

[Phil Ringnalda (:philor)]

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/3cdfed5b85a7 for frequent 10.10 debug e10s media crashes like https://treeherder.mozilla.org/logviewer.html#?job_id=28179738&repo=mozilla-inbound

Comment 29

[Nathan Froyd [:froydnj]]

(In reply to Phil Ringnalda (:philor) from comment #28)
> Backed out in
> https://hg.mozilla.org/integration/mozilla-inbound/rev/3cdfed5b85a7 for
> frequent 10.10 debug e10s media crashes like
> https://treeherder.mozilla.org/logviewer.html#?job_id=28179738&repo=mozilla-
> inbound

Bother.

OK, so the stack says that we're trying to access an invalid pointer, servicing an IPC message for PImageBridgeChild.  This pointer would have been generated from:

http://dxr.mozilla.org/mozilla-central/source/ipc/glue/SharedMemoryBasic_mach.mm#247

Since gParentPid gets set and never changes, somebody must have removed the gParentPid->MemoryPort mapping from gMemoryCommPorts.  That would mean that our access:

  const MemoryPort& parent = gMemoryCommPorts[gParentPid];

is actually creating an entirely new MemoryPort with a null mSender and mReceiver, which would account for the bad pointer that eventually gets passed in to MachPortSender::SendMessage.  Love that STL convenience.

The question then becomes who removed that mapping.  We're somewhere in child process shutdown, so it's entirely possible the parent process has already told us to shutdown, and we removed the mapping ourself.  Or somebody called SharedMemoryBasic::Shutdown.

This seems like the sort of thing that ought to have turned up before, but I can't find any evidence of intermittents or crash reports around this.

Nical, you've done a lot of work around compositor shutdown and whatnot.  Does the above sound sort of plausible to you, and do you have any ideas what we can do about it?  Or, alternatively, do you know who might know more?

Comment 30

[Nicolas Silva [:nical]]

(In reply to Nathan Froyd [:froydnj] from comment #29)
> Nical, you've done a lot of work around compositor shutdown and whatnot. 
> Does the above sound sort of plausible to you, and do you have any ideas
> what we can do about it?  Or, alternatively, do you know who might know more?

IPDL automagically removes shmems when the protocol that manages is destroyed, so it's definitely something to look into.
That said, the stack shows that we are in the shutdown of the media module, which happens before we shut the ImageBridge protocol (and any other gfx-related ipdl thing) down. The things that actually shuts down gfx ipdl protocols like ImageBridge always originate later and from the child process (the parent tells the child process to clean itself up and shut the ipdl protocols down, but stuff that matters for ipdl is sent from the child as a result of that). The exception to this is when an abnormal shutdown occur in which case ipdl shuts everything down right away and we tend to get into a buggy state, but the child process is about to get killed at this point.
Normally the parent process should be waiting for all of its child processes to die before it terminates, I am pretty sure it works at least most of the time because I've been looking into issues related to the parent process waiting for too long. But never say never...

So, unless the ipdl pipe got cut for some unexpected reason and an abnormal shutdown occurred, ipdl on the child should still be in a usable state at this point.
There could also be some fiddly hidden dependencies in the shutdown that we just haven't run into until now, but how that would relate to changing the libstd is pretty mysterious.

Comment 31

[Nathan Froyd [:froydnj]]

So a try run with some debugging confirms that we've initiated child process shutdown:

 17:42:32     INFO -  ]: ]: [Child 1769] ###!!! ASSERTION: calling SharedMemoryBasic::Shutdown!: 'false', file /builds/slave/try-m64-d-00000000000000000000/build/src/ipc/glue/SharedMemoryBasic_mach.mm, line 460
 17:42:32     INFO -  #01: XRE_ShutdownChildProcess [toolkit/xre/nsEmbedFunctions.cpp:671]
 17:42:32     INFO -  #02: mozilla::dom::ContentChild::ActorDestroy(mozilla::ipc::IProtocolManager<mozilla::ipc::IProtocol>::ActorDestroyReason) [xpcom/glue/nsCOMPtr.h:403]
 17:42:32     INFO -  #03: mozilla::dom::PContentChild::DestroySubtree(mozilla::ipc::IProtocolManager<mozilla::ipc::IProtocol>::ActorDestroyReason) [obj-firefox/ipc/ipdl/PContentChild.cpp:9289]
 17:42:32     INFO -  #04: mozilla::dom::PContentChild::OnChannelClose() [obj-firefox/ipc/ipdl/PContentChild.cpp:8895]
 17:42:32     INFO -  #05: mozilla::ipc::MessageChannel::NotifyChannelClosed() [ipc/glue/MessageChannel.cpp:2232]
 17:42:32     INFO -  #06: nsRunnableMethodImpl<void (mozilla::ipc::MessageChannel::*)(), false, true>::Run [xpcom/glue/nsThreadUtils.h:707]
 17:42:32     INFO -  #07: nsThread::ProcessNextEvent(bool, bool*) [xpcom/glue/nsCOMPtr.h:403]
 17:42:32     INFO -  #08: NS_ProcessPendingEvents(nsIThread*, unsigned int) [xpcom/glue/nsThreadUtils.cpp:232]
 17:42:32     INFO -  #09: nsBaseAppShell::NativeEventCallback() [widget/nsBaseAppShell.cpp:98]
17:42:32 INFO - #10: nsAppShell::ProcessGeckoEvents(void*) [widget/cocoa/nsAppShell.mm:388]

which clears out the ports we have for communication.  And then later we have:

 17:42:32     INFO -  [Child 1769] ###!!! ASSERTION: Could not find parent comm ports (parent=1768, requested pid=1768): 'false', file /builds/slave/try-m64-d-00000000000000000000/build/src/ipc/glue/SharedMemoryBasic_mach.mm, line 252
 17:42:32     INFO -  #01: mozilla::ipc::SharedMemoryBasic::ShareToProcess(int, unsigned int*) [ipc/glue/SharedMemoryBasic_mach.mm:621]
 17:42:32     INFO -  #02: mozilla::ipc::SharedMemoryCommon<unsigned int>::ShareHandle(int, IPC::Message*) [ipc/glue/SharedMemory.h:133]
 17:42:32     INFO -  #03: mozilla::ipc::Shmem::ShareTo(mozilla::ipc::Shmem::IHadBetterBeIPDLCodeCallingThis_OtherwiseIAmADoodyhead, int, int) [ipc/glue/Shmem.cpp:480]
 17:42:32     INFO -  #04: mozilla::layers::PImageBridgeChild::CreateSharedMemory(unsigned long, mozilla::ipc::SharedMemory::SharedMemoryType, bool, int*) [obj-firefox/ipc/ipdl/PImageBridgeChild.cpp:585]
 17:42:32     INFO -  #05: mozilla::layers::PImageBridgeChild::AllocUnsafeShmem(unsigned long, mozilla::ipc::SharedMemory::SharedMemoryType, mozilla::ipc::Shmem*) [obj-firefox/ipc/ipdl/PImageBridgeChild.cpp:949]
 17:42:32     INFO -  #06: mozilla::layers::ImageBridgeChild::AllocUnsafeShmem(unsigned long, mozilla::ipc::SharedMemory::SharedMemoryType, mozilla::ipc::Shmem*) [gfx/layers/ipc/ImageBridgeChild.cpp:964]
 17:42:32     INFO -  #07: mozilla::layers::ProxyAllocShmemNow [gfx/layers/ipc/ImageBridgeChild.cpp:1005]
 17:42:32     INFO -  #08: RunnableFunction<void (*)(mozilla::layers::AllocShmemParams *, mozilla::ReentrantMonitor *, bool *), mozilla::Tuple<mozilla::layers::AllocShmemParams *, mozilla::ReentrantMonitor *, bool *> >::Run [ipc/chromium/src/base/task.h:37]
17:42:32 INFO - #09: MessageLoop::RunTask(already_AddRefed<mozilla::Runnable>) [mfbt/RefPtr.h:39]

and then we crash shortly thereafter that as before.

Comment 32

[Pulsebot]

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

Comment 33

[Ryan VanderMeulen [:RyanVM]]

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