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: https://crash-stats.mozilla.com/report/index/68aa6179-c0c0-4c55-a28b-d3f172161124 https://crash-stats.mozilla.com/report/index/39621644-c69d-4fb5-84d6-52a412161123 https://crash-stats.mozilla.com/report/index/08176b38-d15c-4db3-92ba-ba25b2161123 https://crash-stats.mozilla.com/report/index/2785d017-b13f-4840-9e60-48ccc2161123

What happens if you try beta or earlybird from http://www.mozilla.org/en-US/thunderbird/channel/ ?

I'm using Thunderbird 50.0b3 now and I have not encountered this issue yet.

(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

Unfortunately 50.0b3 also crashed on me exactly the same way: https://crash-stats.mozilla.com/report/index/6eeb0c9a-7bd0-4991-a75d-79d362161124 While 45.5.0 crashed on every sleep/wake cycle, 50.0b3 survives some of them but not all.

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

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

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: https://crash-stats.mozilla.com/report/index/589782bb-0479-4e2b-b9ce-d147d2161204 https://crash-stats.mozilla.com/report/index/d3f542a6-1332-4d63-8848-c57752161204

Waking up my MacBook just now with TB still running in Safe Mode with add-ons disables resulted in this crash: https://crash-stats.mozilla.com/report/index/cf8828c9-e4b8-4071-b3cb-9d58e2161204

any smart cards? (ref bug 1218183) And the Mac was never running any OS older than sierra, correct?

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.

Other Sierra stability issues https://mzl.la/2g0FDyB 65% of Mac crashes mentioning sleep are Sierra https://crash-stats.mozilla.com/search/?user_comments=~sleep&platform=Mac%20OS%20X&date=%3E%3D2016-11-27T22%3A38%3A00.000Z&date=%3C2016-12-04T22%3A38%3A00.000Z&_sort=-date&_facets=signature&_facets=email&_facets=platform_version&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=platform_version&_columns=user_comments#facet-platform_version

#1 crash for Firefox 50.0.2 for Macs https://crash-stats.mozilla.com/topcrashers/?platform=Mac%20OS%20X&product=Firefox&version=50.0.2 crashes mentioning sleep - https://crash-stats.mozilla.com/search/?user_comments=~sleep&platform=Mac%20OS%20X&date=%3E%3D2016-11-23T02%3A43%3A28.000Z&date=%3C2016-12-07T02%3A43%3A28.000Z&_sort=platform_version&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=user_comments&_columns=platform_version&_columns=reason#crash-reports from bug 1322294, bp-e2f765e4-06d7-4aa7-8f62-5fd0b2161205 [@ libsystem_kernel.dylib@0x19dda ] for thunderbird 45.5.0

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? https://crash-stats.mozilla.com/signature/?signature=libobjc.A.dylib%400x6b5d&date=%3E%3D2016-12-01T02%3A47%3A00.000Z&date=%3C2016-12-08T02%3A47%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_sort=-date&page=1#correlations ? Based on 3 month graph, these two coincide only to the release of sierra at mid-late September: - https://crash-stats.mozilla.com/signature/?signature=libsystem_kernel.dylib%400x19dda&date=%3E%3D2016-09-08T02%3A55%3A30.000Z&date=%3C2016-12-08T02%3A55%3A30.000Z#graphs - https://crash-stats.mozilla.com/signature/?signature=libobjc.A.dylib%400x6b5d&date=%3E%3D2016-09-08T02%3A55%3A30.000Z&date=%3C2016-12-08T02%3A55%3A30.000Z#graphs I'm not sure how to take the other signature - it's uptick doesn't start until Nov 14 https://crash-stats.mozilla.com/signature/?signature=libobjc.A.dylib%400x6a31&date=%3E%3D2016-09-08T02%3A55%3A51.000Z&date=%3C2016-12-08T02%3A55%3A51.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_sort=-date&page=1#graphs

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.

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.

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.

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.

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

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

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.

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 - http://www.apple.com/shop/buy-mac/macbook-pro?

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.

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

tracking 52/53+ for this mac topcrash

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

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. [1]: https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/pmset.1.html

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.

(lldb) bt * thread #1: tid = 0x412ed, 0x00007fffa4f00a31 libobjc.A.dylib`objc_retain + 33, queue = 'com.apple.main-thread', 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 = 'com.apple.touchbar.agent' 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.

It looks like there's a workaround: http://indiestack.com/2016/12/touch-bar-crashers/ http://indiestack.com/2016/12/touch-bar-crash-protection/ 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

(In reply to Markus Stange [:mstange] from comment #38) > It looks like there's a workaround: > > http://indiestack.com/2016/12/touch-bar-crashers/ > http://indiestack.com/2016/12/touch-bar-crash-protection/ > > 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?

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.

After a day without crashes I connected my MacBook to the charger, took it off, woke it up, and boom! https://crash-stats.mozilla.com/report/index/87e7912f-88c2-4846-af5d-392342161218 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.

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

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.

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?

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.

Sorry, I missed the earlier comment where you noted that.

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

This is currently the top overall crash on Aurora: http://bit.ly/2iHbE1a - 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.

another signature appears to be AppKit@0x3a5126 based on comments in https://crash-stats.mozilla.com/signature/?signature=AppKit%400x3a5126&date=%3E%3D2017-01-06T17%3A58%3A00.000Z&date=%3C2017-01-13T17%3A58%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=platform_version&_sort=-date&page=1

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. See: http://www.mactechnologies.com/wordpress/2017/01/avoiding-wake-from-sleep-crashes-with-the-touchbar-macbook-pro/ 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

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

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). [snip]

As it is fixed upstream, not adding it to the release notes.

Added to 50.0 / 50.1.0 release notes, as the Apple fix is not yet released.

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.

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) https://crash-stats.mozilla.com/search/?platform_version=~10.12.3&user_comments=~sleep&platform=Mac%20OS%20X&date=%3E%3D2017-01-24T22%3A19%3A42.000Z&date=%3C2017-01-31T22%3A19%3A42.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=platform&_columns=user_comments#crash-reports * 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 https://crash-stats.mozilla.com/search/?platform_version=~10.12.2&user_comments=~sleep&platform=Mac%20OS%20X&date=%3E%3D2017-01-24T22%3A19%3A42.000Z&date=%3C2017-01-31T22%3A19%3A42.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=platform&_columns=user_comments#crash-reports

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.

On a related note, 10.12.4 had some correctness fixes as well, especially on 13" models.

(In reply to Marcia Knous [:marcia - use ni] from comment #60) > 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. Shall we close this invalid and the ESRs as wontfix?