Firefox and Thunderbird crash in libobjc.A.dylib@0x6b5d consistently when waking from sleep with macOS Sierra [10.12]




8 months ago
4 months ago


(Reporter: Richard van den Berg, Unassigned)


(4 keywords)

45 Branch
Mac OS X
crash, reproducible, topcrash-mac, topcrash-thunderbird

Firefox Tracking Flags

(firefox50 wontfix, firefox51 wontfix, firefox52+ wontfix, firefox53+ wontfix, relnote-firefox 50+)


(Whiteboard: [tbird crash][fixed by macOS 10.12.3], crash signature)



8 months ago
This bug was filed from the Socorro interface and is 
report bp-39621644-c69d-4fb5-84d6-52a412161123.

Whenever I put my MacBook Pro 15" late 2016 (MacBookPro13,3) to sleep by closing the lid, Thunderbird will crash when I wake it up. The MacBook is running macOS Sierra 10.12.1.

I have 4 identical crash reports:
What happens if you try beta or earlybird from ?
Flags: needinfo?(richard)

Comment 2

8 months ago
I'm using Thunderbird 50.0b3 now and I have not encountered this issue yet.
Flags: needinfo?(richard)
(In reply to Richard van den Berg from comment #2)
> I'm using Thunderbird 50.0b3 now and I have not encountered this issue yet.

That's good news. ALthough I cannot say what might have fixed it, the core folks might have patched this
Last Resolved: 8 months ago
Resolution: --- → WORKSFORME

Comment 4

8 months ago
Unfortunately 50.0b3 also crashed on me exactly the same way:
While 45.5.0 crashed on every sleep/wake cycle, 50.0b3 survives some of them but not all.
Resolution: WORKSFORME → ---
Crash Signature: [@ libobjc.A.dylib@0x6b5d] → [@ libobjc.A.dylib@0x6b5d] [@ libobjc.A.dylib@0x6a31 ]

Comment 5

8 months ago
What might be interesting to know is that Crash Report itself sometimes also crashes. When Crash Reporter is running (telling me Thunderbird has crashed) but I don't dismiss it, another sleep-wake cycle later it crashes as well.
mstange, what do you make of these crashes?

Richard, you have 21 crashes in about 1 week. Is this reproducible for on *every* wake?  If not, what precentage?  And does it also crash when stared in Thunderbird Safe mode?

Another crash signature - libsystem_kernel.dylib@0x19dda bp-5d5c94c3-0f6e-45b6-a5b1-bd35e2161115 "OS X failed, going from sleep mode to restart."
ref bug 1286613
Flags: needinfo?(richard)
Flags: needinfo?(mstange)
Keywords: reproducible

Comment 7

8 months ago
Yes, it seems I reproduced this at every wake. Because the MacBook is very fast waking from sleep, it is not always clear if it actually sleeping. I am now running in Safe Mode (with add-ons disabled) and TB did not crash the last few sleep/wakes. I'll report back if that situation changes (or not).
Flags: needinfo?(richard)

Comment 8

8 months ago
I don't use Firefox as my main browser on this MacBook but I left FF 50.0.2 running in the background today. This resulted in 2 similar crashes on sleep/wake:

Comment 9

8 months ago
Waking up my MacBook just now with TB still running in Safe Mode with add-ons disables resulted in this crash:
any smart cards?   (ref bug 1218183)
And the Mac was never running any OS older than sierra, correct?
Flags: needinfo?(richard)

Comment 11

8 months ago
I don't use any smart cards on this laptop. This MacBook Pro came with macOS Sierra 10.12.1 out of the box. I did copy my TB profile from another Mac though.
Flags: needinfo?(richard)
Other Sierra stability issues

65% of Mac crashes mentioning sleep are Sierra
Component: Untriaged → General
Product: Thunderbird → Core
Summary: Crash in libobjc.A.dylib@0x6b5d consistently when waking from sleep on MacBook Pro late 2016 → Firefox and Thunderbird crash in libobjc.A.dylib@0x6b5d consistently when waking from sleep on MacBook Pro late 2016
Duplicate of this bug: 1322294
#1 crash for Firefox 50.0.2 for Macs

crashes mentioning sleep -

from bug 1322294, bp-e2f765e4-06d7-4aa7-8f62-5fd0b2161205 [@ libsystem_kernel.dylib@0x19dda ] for thunderbird 45.5.0
Crash Signature: [@ libobjc.A.dylib@0x6b5d] [@ libobjc.A.dylib@0x6a31 ] → [@ libobjc.A.dylib@0x6b5d] [@ libobjc.A.dylib@0x6a31 ] [@ libsystem_kernel.dylib@0x19dda ]
Keywords: topcrash-mac
Summary: Firefox and Thunderbird crash in libobjc.A.dylib@0x6b5d consistently when waking from sleep on MacBook Pro late 2016 → Firefox and Thunderbird crash in libobjc.A.dylib@0x6b5d consistently when waking from sleep with macOS Sierra [10.12]
Whiteboard: [tbird crash]
It looks like between Firefox and Thunderbird there are over 4K crashes in the last seven days. Is this only happening with the newer Mac hardware?
(In reply to Marcia Knous [:marcia - use ni] from comment #15)
> It looks like between Firefox and Thunderbird there are over 4K crashes in
> the last seven days. Is this only happening with the newer Mac hardware?

Is the HW correlation revealed in correlation tab? ?

Based on 3 month graph, these two coincide only to the release of sierra at mid-late September:

I'm not sure how to take the other signature - it's uptick doesn't start until Nov 14

Comment 17

8 months ago
I have a 2016 MacBook Pro 15" with 512 GB HDD and FileVault switched ON.  I installed all apps on this new notebook fresh--I did not restore from backup or do a migration assistant of any kind.  I'm getting regular crashes in FireFox 50.0.2.  While I cannot be absolutely certain, I *think* the crashes happen when the notebook goes to sleep and is plugged in to wall power.  It does not seem to happen when the notebook remains on battery power alone.  I also have switched ON "Enable Power Nap while plugged in to a power adapter."

Not sure if any of these things are related but perhaps others can try a similar set up and maybe we can reproduce a highly specific crash.

Comment 18

8 months ago
I have had this problem with my 2016 Macbook Pro same as g-bugzilla above, purchased Dec. 1. It is quite repeatable with Thunderbird 45.5.1 and Firefox 50.0.2 when waking from a sleep state, whether the sleep was commanded or from a timeout. I am running Sierra 10.12.1 (16B2659). My experience also agrees with the report that the crash report itself often appears to crash, though that is not repeatable. I do not have the problem with my late 2011 Macbook Pro running El Capitan, though with the same Firefox and Thunderbird, which suggests it's either a problem with the new hardware or Sierra.

Comment 19

8 months ago
Add to my previous comments: I agree with the report of g-bugzilla above that the crash doesn't happen when NOT plugged in to wall power, only when it IS plugged in.

Comment 20

8 months ago
In contrary to comment 19 I do see the crashes when on battery power. I also got them when plugged in to an external power source, but ticking the box for "Prevent computer from sleeping automatically when the display is off" in the macOS System Preferences -> Energy Saver -> Power Adapter settings solved that.

Comment 21

8 months ago
Thanks, Richard van den Berg. I have set the "Prevent computer from sleeping..." option and both Thunderbird and Firefox are behaving fine. That should be a big clue, but not an excuse to ignore this bug, which is apparently affecting a lot of people.
now approx #10 crash overall for Thunderbird
approx #40 for Firefox
Keywords: topcrash-thunderbird
[Tracking Requested - why for this release]: Mac top crash on 50 release and will likely carry over to the 51 release.

I was at the Apple store today and tried to reproduce this on 2 machines (15" and 13" with touchbar) Unfortunately the Apple machines are under an admin password which cannot be altered by store personnel, so it prevented me from being able to fully test the 2 machines. I also found out they are imaged at Apple corporate so they may be different than the out of the box machine bought at the store.

Simply sleeping and waking the machine did not work. Wondering if anyone seeing the bug sees it immediately after waking, or is time involved (like overnight?).
tracking-firefox52: --- → ?

Comment 24

8 months ago
Yes. Upon waking the two apps (Firefox and Thunderbird) are both inactive and there are crash notices, although they vary - sometimes they can "notify Apple" and other times not. It seems to be more associated with the machine sleeping voluntarily (power saving) after a delay, but I can't confirm that.

Comment 25

8 months ago
For my experience, I've seen it very regularly when I close the lid, plug in the laptop, and leave it for an extended period.  For me this is typically charging the machine overnight after using it all day.  I noticed the other day that I did NOT unplug the machine before opening the lid (i.e. opened the lid with laptop still plugged in to wall power) and Firefox was still active and working properly.  That same day, I unplugged the machine, closed the lid, came back at a later time, and began using the laptop again.  It was at this point that FF crashed--after removing wall power and a sleep event happening.

I don't have the patience to do extensive testing but I'll try one or two things if someone has an idea.

Since FF maintains a record of its last state prior to crashing and allows you to reopen the application along with all your tabs, this is more of an annoyance than a real problem.  It *is* annoying, though.
(In reply to g-bugzilla from comment #25)
> snip

Can I get your exact machine specs -

Comment 27

8 months ago
MacBook Pro 15-inch, Late 2016 (MacBookPro13,3)
Processor:  2.6 GHz Intel Core i7
Memory:  16 GB 2133 MHz LPDDR3
Graphics:  Intel HD Graphics 530 1536 MB / AMD Radeon Pro 450 2048 MB
Storage:  APPLE SSD SM0512L 500 GB

Is that sufficient?  I'm happy to provide more detail if you would like.
Duplicate of this bug: 1323297
(In reply to Marcia Knous [:marcia - use ni] from comment #23)
> Simply sleeping and waking the machine did not work. Wondering if anyone
> seeing the bug sees it immediately after waking, or is time involved (like
> overnight?).

It seems like time is definitely a factor. Firefox Beta (51) seems to consistently crash when waking up after sleeping for at least a few hours.


8 months ago
Duplicate of this bug: 1322357
tracking 52/53+ for this mac topcrash
status-firefox52: --- → affected
status-firefox53: --- → affected
tracking-firefox52: ? → +
tracking-firefox53: --- → +

Comment 32

8 months ago
Upgraded to 10.12.2, probelm is not fixed...
MacBook Pro "15 2016(touch bar)

Comment 33

7 months ago
I upgraded to macOS 10.12.2, also no change with regard to this issue. I just did some testing with pmset[1] while on battery power:

1) changed hibernatemode to 25 + sleep MacBook = no crash
2) changed hibernatemode to 3 + standbydelay to 10 + sleep MacBook for 15 seconds = crash
3) changed standbydelay back to default of 10800

Repeating step 2 did not produce a crash 100% of the time, but hopefully it helps in reproducing the problem. I used "pmset -b" to set the values and Apple Menu -> Sleep to force the MacBook to sleep.


Comment 34

7 months ago
Rerouted from bug 1322357

I have a crash report now, ID: bp-1b665ba2-d277-4878-9cc9-f02272161215
(In reply to Richard van den Berg from comment #33)
> 2) changed hibernatemode to 3 + standbydelay to 10 + sleep MacBook for 15
> seconds = crash

Thank you very much! I have successfully reproduced the crash this way and was able to attach a debugger.

I'll update this bug as I find out more.

The crash is inside -[CALayer layoutSubLayers] when attempting to call [someObj retain] on an invalid pointer (just before a call to CA::Transaction::unlock()). Not sure yet how much we can do about this, because it's all inside Apple code and we don't really use CALayers in Firefox at all. It is remotely possible that we're handing an invalid pointer to an Apple API, but my guess is that this is an honest bug somewhere in CoreAnimation that is exposed in Firefox because our memory allocator overwrites freed memory with poison values.
Flags: needinfo?(mstange)
(lldb) bt
* thread #1: tid = 0x412ed, 0x00007fffa4f00a31 libobjc.A.dylib`objc_retain + 33, queue = '', stop reason = EXC_BAD_ACCESS (code=1, address=0x65e5e5e5e600)
  * frame #0: 0x00007fffa4f00a31 libobjc.A.dylib`objc_retain + 33
    frame #1: 0x00007fff960e7d32 QuartzCore`-[CALayer layoutSublayers] + 194
    frame #2: 0x00007fff960db210 QuartzCore`CA::Layer::layout_if_needed(CA::Transaction*) + 366
    frame #3: 0x00007fff960db08e QuartzCore`CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 24
    frame #4: 0x00007fff960d0878 QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 280
    frame #5: 0x00007fff95fc7631 QuartzCore`CA::Transaction::commit() + 475
    frame #6: 0x00007fff8e1fd445 AppKit`__37+[NSDisplayCycle currentDisplayCycle]_block_invoke.31 + 323
    frame #7: 0x00007fff902b9397 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
    frame #8: 0x00007fff902b9307 CoreFoundation`__CFRunLoopDoObservers + 391
    frame #9: 0x00007fff90299f39 CoreFoundation`__CFRunLoopRun + 873
    frame #10: 0x00007fff90299974 CoreFoundation`CFRunLoopRunSpecific + 420
    frame #11: 0x00007fff8f825acc HIToolbox`RunCurrentEventLoopInMode + 240
    frame #12: 0x00007fff8f825901 HIToolbox`ReceiveNextEventCommon + 432
    frame #13: 0x00007fff8f825736 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71
    frame #14: 0x00007fff8ddcbae4 AppKit`_DPSNextEvent + 1120
    frame #15: 0x00007fff8e54621f AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2789
    frame #16: 0x0000000118b5e496 XUL`-[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 86
    frame #17: 0x00007fff8ddc0465 AppKit`-[NSApplication run] + 926
    frame #18: 0x0000000118b5f3aa XUL`nsAppShell::Run() + 234
    frame #19: 0x00000001195e5f89 XUL`nsAppStartup::Run() + 41
    frame #20: 0x000000011966a980 XUL`XREMain::XRE_mainRun() + 3696
    frame #21: 0x000000011966ae4c XUL`XREMain::XRE_main(int, char**, mozilla::XREAppData const&) + 700
    frame #22: 0x000000011966b1a2 XUL`XRE_main + 226
    frame #23: 0x000000010df68976 firefox`main + 1862
    frame #24: 0x000000010df68224 firefox`start + 52
(lldb) p (void*)$rax
(void *) $2 = 0xe5e5e5e5e5e5e5e5
(lldb) bt all
  thread #64: tid = 0x41977, 0x00007fffa59213b2 libsystem_kernel.dylib`__ulock_wait + 10, queue = ''
    frame #0: 0x00007fffa59213b2 libsystem_kernel.dylib`__ulock_wait + 10
    frame #1: 0x00007fffa5a02b5f libsystem_platform.dylib`_os_ulock_wait + 25
    frame #2: 0x00007fffa5a02432 libsystem_platform.dylib`_os_unfair_lock_lock_slow + 130
    frame #3: 0x00007fff960dbe11 QuartzCore`CA::Layer::set_visible(unsigned int) + 183
    frame #4: 0x00007fff960cef21 QuartzCore`CA::Context::invalidate() + 75
    frame #5: 0x00007fff9c1ec7bd DFRFoundation`-[DFRElement dealloc] + 113
    frame #6: 0x00007fffa4f08db7 libobjc.A.dylib`objc_object::sidetable_release(bool) + 285
    frame #7: 0x00007fffa5826952 libsystem_blocks.dylib`_Block_release + 102
    frame #8: 0x00007fffa57bc0b8 libdispatch.dylib`_dispatch_client_callout + 8
    frame #9: 0x00007fffa57d2ae5 libdispatch.dylib`_dispatch_queue_serial_drain + 896
    frame #10: 0x00007fffa57c4cd9 libdispatch.dylib`_dispatch_queue_invoke + 1046
    frame #11: 0x00007fffa57bde70 libdispatch.dylib`_dispatch_root_queue_drain + 476
    frame #12: 0x00007fffa57bdc47 libdispatch.dylib`_dispatch_worker_thread3 + 99
    frame #13: 0x00007fffa5a09712 libsystem_pthread.dylib`_pthread_wqthread + 1299
    frame #14: 0x00007fffa5a091ed libsystem_pthread.dylib`start_wqthread + 13

It looks like the touchbar is doing something with CALayers that causes the CoreAnimation transaction on the main thread to access uninitialized / freed memory.
I have filed a radar bug with ID 29693717 about this.

Comment 38

7 months ago
It looks like there's a workaround:

Apparently this affects us because we build with an older SDK. So this is another point of evidence that we should look at upgrading to more recent SDKs sooner.
Awesome, thanks Markus!

The workaround for Firefox is:

  defaults write org.mozilla.firefox NSFunctionBarAPIEnabled -bool NO

Note that this will disable the Touch Bar for Firefox. After this bug has been fixed, you may want to re-enable it with:

  defaults delete org.mozilla.firefox NSFunctionBarAPIEnabled

Comment 40

7 months ago
(In reply to Markus Stange [:mstange] from comment #38)
> It looks like there's a workaround:
> Apparently this affects us because we build with an older SDK. So this is
> another point of evidence that we should look at upgrading to more recent
> SDKs sooner.

Is there a bug on file to switch to the 10.9 SDK (which IIRC is the oldest version of OS X we currently support)? Is there a lot holding that up beyond testing?
Flags: needinfo?(mstange)

Comment 41

7 months ago
Thanks Markus and Birunthan! I have been running with

  defaults write org.mozilla.firefox NSFunctionBarAPIEnabled -bool NO
  defaults write org.mozilla.thunderbird NSFunctionBarAPIEnabled -bool NO

and did not experience any crashes today.

Comment 42

7 months ago
After a day without crashes I connected my MacBook to the charger, took it off, woke it up, and boom!
This is with org.mozilla.thunderbird NSFunctionBarAPIEnabled set to NO.
This bug seems to be fixed in 10.12.3 Beta 2 (16D17a).

(In reply to :Gijs Kruitbosch from comment #40)
> Is there a bug on file to switch to the 10.9 SDK (which IIRC is the oldest
> version of OS X we currently support)? Is there a lot holding that up beyond
> testing?

coop filed bug 1324892. I don't know if that's the only thing (beyond testing) that is holding this up.
Bug 1312649 comment 10 is another instance of a problem that would be solved by building with the 10.12 SDK.
Flags: needinfo?(mstange)

Comment 44

7 months ago
I have another crash report if that helps: bp-1d69bdf5-7004-420e-8273-fd70e2161221


7 months ago
status-firefox50: --- → affected
status-firefox51: --- → affected

Comment 45

7 months ago
I am experiencing the same issue with a new 2016 15" MBP. Sierra 10.12.2 [16C67] with latest patches and running latest firefox and thunderbird. Either with addons disabled or not if I close laptop and go to sleep both apps are not running when I come out of sleep mode... crash reporter is usually running for both but not always.

Comment 46

7 months ago
I used the terminal command listed above originally by Markus and Birunthan.  The command repeated here is:

defaults write org.mozilla.firefox NSFunctionBarAPIEnabled -bool NO

After executing this in Terminal, I have been running Firefox normally for about 10 days--both with and without wall power--and have had exactly zero crashes.

I don't know if this is the root cause but it certainly fixed my problem.

Thank you to all who have bug-hunted and contributed to this work-around!
This is the #1 topcrash on 52 over the last week (impressive given that it's Mac-only), which is also slated to be our next ESR release. What needs to be done to move this bug forward?
Flags: needinfo?(mstange)
Apple needs to release 10.12.3 which fixes the crash. I don't think it's worth landing a workaround for the (hopefully) few remaining days.
Flags: needinfo?(mstange)
Sorry, I missed the earlier comment where you noted that.
Whiteboard: [tbird crash] → [tbird crash][fixed by macOS 10.12.3]
Maybe we should add a note to the 50+ release notes. I have run into users that have hit this in the wild and believe it was Firefox issue.

Release Note Request (optional, but appreciated)
[Why is this notable]: Crashes on Macbook Pro computers with the touch bar
[Affects Firefox for Android]: no
[Suggested wording]: Due to an Apple touch bar bug Firefox may crash when open for long periods or crash after resuming from sleep. Apple reports to have a fix for this in the currently unreleased OS X 10.12.3
[Links (documentation, blog post, etc)]: this bug
relnote-firefox: --- → ?
This is currently the top overall crash on Aurora: - it is #8 overall browser crash on nightly. In the latest beta it is the top Mac crash, but doesn't appear as high in the overall top browser crashes.
See Also: → bug 1286613
another signature appears to be AppKit@0x3a5126 based on comments in

Comment 53

7 months ago
I also have a 2016 MacBook Pro running OS X 10.12.2 (Sierra) and have seen the issue with both FF50.x and TB45.6.0.  

Researching the issue, I came across a different workaround.

I have applied both of these, and they seem to be working:
defaults write 'org.mozilla.firefox' NSLayerPerformanceUpdates -bool YES
defaults write 'org.mozilla.thunderbird' NSLayerPerformanceUpdates -bool YES
See Also: → bug 1308883

Comment 54

6 months ago
One addendum to Comment 53: 

The crashreporter itself is subject to this issue. The workaround setting must also be applied to crashreporter.

defaults write 'org.mozilla.crashreporter' NSLayerPerformanceUpdates -bool YES
Crash Signature: [@ libobjc.A.dylib@0x6b5d] [@ libobjc.A.dylib@0x6a31 ] [@ libsystem_kernel.dylib@0x19dda ] → [@ libobjc.A.dylib@0x6b5d] [@ libobjc.A.dylib@0x6a31 ] [@ libsystem_kernel.dylib@0x19dda ] [@ AppKit@0x3a5126 ]
Duplicate of this bug: 1331144

Comment 56

6 months ago
I'm having the same crash problems with my Late 2016 15" Macbook Pro. FF crashes on every wake cycle and so does the reporter when i try to send it to FF. FF says they are working on a bug fix. I'm not familiar enough with the software "work around" mentioned to make the changes needed. I'm using Safari and this is the Hardware Overview:

  Model Name:	MacBook Pro
  Model Identifier:	MacBookPro13,3
  Processor Name:	Intel Core i7
  Processor Speed:	2.7 GHz
  Number of Processors:	1
  Total Number of Cores:	4
  L2 Cache (per Core):	256 KB
  L3 Cache:	8 MB
  Memory:	16 GB
  Boot ROM Version:	MBP133.0226.B08
  SMC Version (system):	2.38f6
  Serial Number (system):	C02SN349GTFM
  Hardware UUID:	EC19867C-37A9-51B2-A0ED-C143D0A7008B

I'm supplying this info in an effort to help FF with the bug fix. I'm using Google Chrome and have other issues with app that I use for a live video/audio feed from Manheim Auto Auctions Simulcasts. FF works fine in this App but crashes on awake. Frustrating.
(In reply to Ken Gamble from comment #56)

This has to be fixed on the Apple side, and should be fixed with the next release (10.12.3).

As it is fixed upstream, not adding it to the release notes.
relnote-firefox: ? → ---
Added to 50.0 / 50.1.0 release notes, as the Apple fix is not yet released.
relnote-firefox: --- → 50+
I updated my machine (MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports) to 10.12.3, and I haven't yet encountered this crash.

We will wait for more data to come in to see if there are any further crashes on 16D32. Phillip mentioned there is still one user running 16D32 that is still crashing in this signature. I noticed when I looked at that crash signature that the person has a different machine architecture than I do.
I updated my 2016 late 15" MacBook Pro to 10.12.3 and the crash never happened so far.
Duplicate of this bug: 1324424
For both Firefox and Thunderbird for past 7 days, and with 10.12.3 out for allmost 2 weeks:

relevant to comment 60...
10.12.3 - only 2 crashes mention sleep (both crashes have reporter email)
* CoreVideo@0xbe03 bp-94fd6dba-76b3-4104-9c6f-e5c202170131 51.0.1 20170125094131 OS X 0.12.3 16D32
* CoreVideo@0xbe03 bp-41a24e29-d837-4df3-a1db-432d62170130 51.0 20170118123726 OS X 10.12.3 16D32

compare 10.12.2 - 76 crashes mention sleep
Sounds like the fix came from Apple about 6 weeks ago and the crash rate is tapering off gradually as we would expect. With the crash signatures listed here, I'm only seeing a few scattered crashes (under 10 per week) for beta 53.
status-firefox50: affected → wontfix
status-firefox51: affected → wontfix
status-firefox52: affected → wontfix
status-firefox53: affected → wontfix
On a related note, 10.12.4 had some correctness fixes as well, especially on 13" models.
You need to log in before you can comment on or make changes to this bug.