The one that just froze my work Mac Pro was the latter for 15.6.0. However, this is with a Mac Pro while the other was with a Macbook Pro, so it's not directly related to a specific graphics driver.

panic(cpu 12 caller 0xffffff801d518b7f): "No more room to grow table: 0x0xffffff801dcb3e00 size:262142, used:262141, requested elem:1"@/Library/Caches/com.apple.xbs/Sources/xnu/xnu-3248.70.3/osfmk/kern/waitq.c:594
Backtrace (CPU 12), Frame : Return Address
0xffffff93f8493d60 : 0xffffff801d4dab52 
0xffffff93f8493de0 : 0xffffff801d518b7f 
0xffffff93f8493e60 : 0xffffff801d516122 
0xffffff93f8493e70 : 0xffffff801d4d43ac 
0xffffff93f8493ee0 : 0xffffff801d4d1bb8 
0xffffff93f8493f10 : 0xffffff801d5b921a 
0xffffff93f8493fb0 : 0xffffff801d5ed4c6 

This might be related to  bug 755623 . In that bug Chrome froze in some weird deep way when entering a hangout, and in this one it kernel panicked.

 Issue 755623  was reported against 62.0.3175.4. Can we assume that your panics were reported on that verison?

I don't know.

The version that I'm running right now is 62.0.3178.0. I know the hang happened with 3175.4. I then restarted Chrome, and there's obviously been an autoupdate since then, but I don't know if it was before or after the panic. I tend to leave my Chromes running a lot, so it's possible the autoupdate happened before the panic but I kept the old version running.

In general, I can't assume that the version of Chrome on my machine after I reboot from a panic is the one that was running at the time of the panic.

I think I've found a potential xnu issue.

It would be extremely helpful to know if this occurred only on 62.0.3178.0, or if 3175.4 was affected as well.

I'm not sure how to help you there. Perhaps download 3175.4, disable autoupdating (not sure how, offhand) and run it for a week?

I honestly don't know how to determine which was the version running at the time of the panic.

This is a longshot, but if you look in Console.app, do you have any other reports from Chrome Canary?  I've got about 5 "wakeups_resource.diag" files per day -- if you do too, you could pick one that's timestamped just before the kernel panic and we can be pretty confident that it'll list the correct version of Chrome.

I'll check tomorrow. This was my work computer, BTW, at which I run my personal profile in Canary and my work profile in Dev. It panicked when I entered a Hangout in my Dev Chrome, though I'd run some videos on YouTube in Canary.

Rohit, Robert: I can find nothing about wakeups in my logs that would help.

Re the other bug, yes, this is a flaw in macOS, but we've changed something in Chrome to poke at it, as it's new. Unless that was introduced by Apple in a security fix or something.

Yup, I'm not saying it isn't new. But without knowing affected versions, the root cause is going to be tricky to pin down.

How many tabs/other processes did you, Rohit, or Erik have open at the time of the panic?

At work, more than a hundred other tabs. At home, less than 20, certainly.

I want to say ~50 at the time I hit a kernel panic.

This just happened on my work Mac while watching a YouTube video on 3188.0 canary.

And it juuust happened again. About twenty minutes of YouTube time in Canary that had a dozen tabs, though my Dev Chrome has 144 tabs open.

This tends to happen with YouTube and Hangouts, so including some graphics peeps.

Graphics peeps, have we made any graphics changes lately?

Not sure of any specific changes that might affect this case. Does the GPU process grow over time while you're watching the YouTube video?

What's about:gpu from an affected system?

Is there any way to get a userland stack that issues this syscall when the kernel crashes? It could help narrow things down.

It's also worth seeing if disabling accelerated video decode (via about:flags) changes things.

I have a hypothesis that this is being exacerbated by the new WaitableEvent::WaitMany implementation, which is why knowing if it this issue occurred before or after 62.0.3176.0 would be very helpful. If it does happen before 62.0.3176.0, then none of the following matters.

I wrote a dtrace script (attached) to probe all mach_port_insert_member() and port set allocation. It can be run after SIP is disabled by doing `sudo dtrace -s mach-waitq.d`. It will run until it's ^C interrupted, collecting data about those calls. It probably won't report results if the system panics, so run it for a little while and then stop it.

It will print out three listings: the first is caller counts to mach_port_insert_member by process name and PID. The second is the same listing for mach_port_allocate of port sets.

The last listing will be the top 20 stack frames, by PID, into mach_port_allocate for port sets. Note that for Google Chrome it will just print raw instruction pointers unless you've also downloaded the dSYM bundle for the version(s) of Chrome being run. So if the symbols aren't present on the machine and findable by CoreSymbolication, you should note the load address of the "Google Chrome Framework" module for the PIDs of interest. If the symbols are present, dtrace will chew on them for a while.

What I noticed when I ran this my script for a brief period of time was that this stack came up a lot:

0x1162a41a0 [Google Chrome Framework -	 waitable_event_mac.cc:160] base::WaitableEvent::WaitMany(base::WaitableEvent**, unsigned long)
0x116311b50 [Google Chrome Framework -	 wait_set.cc:134] mojo::WaitSet::State::Wait(base::WaitableEvent**, unsigned long*, mojo::Handle*, unsigned int*, MojoHandleSignalsState*)
0x11630ebc0 [Google Chrome Framework -	 sync_handle_registry.cc:84] mojo::SyncHandleRegistry::Wait(bool const**, unsigned long)
0x1164b5ca0 [Google Chrome Framework -	 ipc_sync_message_filter.cc:30] IPC::SyncMessageFilter::Send(IPC::Message*)
0x1147ebe70 [Google Chrome Framework -	 gpu_channel_host.cc:248] gpu::GpuChannelHost::ValidateFlushIDReachedServer(int, bool)
0x1170d7b40 [Google Chrome Framework -	 gles2_implementation.cc:6197] gpu::gles2::GLES2Implementation::VerifySyncTokensCHROMIUM(signed char**, int)
0x116e70280 [Google Chrome Framework -	 resource_provider.cc:1443] cc::ResourceProvider::PrepareSendToParent(std::__1::vector<unsigned int, std::__1::allocator<unsigned int> > const&, std::__1::vector<viz::TransferableResource, std::__1::allocator<viz::TransferableResource> >*)
0x116ec3090 [Google Chrome Framework -	 layer_tree_host_impl.cc:1684] cc::LayerTreeHostImpl::DrawLayers(cc::LayerTreeHostImpl::FrameData*)
0x116ef34d0 [Google Chrome Framework -	 proxy_impl.cc:641] cc::ProxyImpl::DrawInternal(bool)
0x116ef33d0 [Google Chrome Framework -	 proxy_impl.cc:529] cc::ProxyImpl::ScheduledActionDrawIfPossible()
0x116e7fa80 [Google Chrome Framework -	 scheduler.cc:572] cc::Scheduler::DrawIfPossible()
0x116e7d060 [Google Chrome Framework -	 scheduler.cc:614] cc::Scheduler::ProcessScheduledActions()
0x116e7cf00 [Google Chrome Framework -	 scheduler.cc:555] cc::Scheduler::OnBeginImplFrameDeadline()
0x116245290 [Google Chrome Framework -	 task_annotator.cc:33] base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
0x115cea980 [Google Chrome Framework -	 task_queue_manager.cc:477] blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue(blink::scheduler::internal::WorkQueue*, bool, blink::scheduler::LazyNow, base::TimeTicks*)
0x115ce8d80 [Google Chrome Framework -	 task_queue_manager.cc:281] blink::scheduler::TaskQueueManager::DoWork(bool)
0x116245290 [Google Chrome Framework -	 task_annotator.cc:33] base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
0x11626b500 [Google Chrome Framework -	 message_loop.cc:391] base::MessageLoop::RunTask(base::PendingTask*)
0x11626bb10 [Google Chrome Framework -	 message_loop.cc:496] base::MessageLoop::DoWork()

… which could explain why GPU-heavy activity (YT, Hangouts) would trigger this. But the other thing I noticed is that mach_port_insert_member() is called all the time by tons of things during normal use. I can probably write WaitMany to avoid the creation of a port set, which may make this less likely to happen, but it in no way can guarantee that normal mach_port_insert_member() activity wouldn't trigger this on a system with a lot of running processes.

Deleted: mach-waitq.d 341 bytes

mach-waitq.d 341 bytes View Download

Thanks for the investigation. We are branching in few days, it would be great to have a fix ASAP.

 Issue 757903  has been merged into this issue.

This also happened to me 4 times in the last 5-6 days. Chrome version: 62.0.3192.0 (Official Build) dev (64-bit). I didn't notice any patterns, but I also use youtube for hours daily.

panic(cpu 0 caller 0xffffff80064f96b5): "No more room to grow table: 0x0xffffff8006ce5560 size:262142, used:262141, requested elem:1"@/Library/Caches/com.apple.xbs/Sources/xnu/xnu-3789.70.16/osfmk/kern/ltable.c:461
Backtrace (CPU 0), Frame : Return Address
0xffffff91f5463d40 : 0xffffff80064e953c 
0xffffff91f5463dc0 : 0xffffff80064f96b5 
0xffffff91f5463e50 : 0xffffff800652ff64 
0xffffff91f5463e70 : 0xffffff80064e1a2c 
0xffffff91f5463ee0 : 0xffffff80064de648 
0xffffff91f5463f10 : 0xffffff80065ea198 
0xffffff91f5463fb0 : 0xffffff800649adb6 

BSD process name corresponding to current thread: Google Chrome He

Mac OS version:
16G29

This kernel panic also happened to me several times in the past 2 weeks. Chrome Dev 64bit 62.0.3192.0. I use Chrome to watch video on bilibili.com daily, 4-6 tabs opened always, don't quit Chrome.

Anonymous UUID:       22F1054C-C5FC-6B95-DCB6-A1385401E9B2

Fri Aug 25 00:53:31 2017

*** Panic Report ***
panic(cpu 4 caller 0xffffff8016cf96b5): "No more room to grow table: 0x0xffffff80174e5560 size:262142, used:262141, requested elem:1"@/Library/Caches/com.apple.xbs/Sources/xnu/xnu-3789.70.16/osfmk/kern/ltable.c:461
Backtrace (CPU 4), Frame : Return Address
0xffffff9241c73d40 : 0xffffff8016ce953c 
0xffffff9241c73dc0 : 0xffffff8016cf96b5 
0xffffff9241c73e50 : 0xffffff8016d2ff64 
0xffffff9241c73e70 : 0xffffff8016ce1a2c 
0xffffff9241c73ee0 : 0xffffff8016cde648 
0xffffff9241c73f10 : 0xffffff8016dea198 
0xffffff9241c73fb0 : 0xffffff8016c9adb6 

BSD process name corresponding to current thread: Google Chrome

Mac OS version:
16G29

Kernel version:
Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64
Kernel UUID: D3314D98-5D40-3CD8-98A4-F1DD46C20E03
Kernel slide:     0x0000000016a00000
Kernel text base: 0xffffff8016c00000
__HIB  text base: 0xffffff8016b00000
System model name: MacBookPro11,5 (Mac-06F11F11946D27C5)

System uptime in nanoseconds: 305614213797690
last loaded kext at 228968886819296: com.apple.driver.AppleXsanScheme	3 (addr 0xffffff7f9abde000, size 32768)
last unloaded kext at 229048325236986: com.apple.driver.AppleXsanScheme	3 (addr 0xffffff7f9abde000, size 32768)
loaded kexts:
com.paragon-software.filesystems.ntfs	318.3.14
com.globaldelight.driver.Boom2Device	1.1
com.apple.filesystems.smbfs	3.1.2
com.apple.driver.AppleHSBluetoothDriver	114
com.apple.filesystems.autofs	3.0
com.apple.driver.AGPM	110.23.17
com.apple.driver.ApplePlatformEnabler	2.7.0d0
com.apple.driver.X86PlatformShim	1.0.0
com.apple.driver.AppleHDA	279.48
com.apple.driver.AppleGraphicsDevicePolicy	3.14.49
com.apple.driver.AudioAUUC	1.70
com.apple.driver.AppleUpstreamUserClient	3.6.4
com.apple.kext.AMDFramebuffer	1.5.1
com.apple.driver.pmtelemetry	1
com.apple.iokit.IOUserEthernet	1.0.1
com.apple.AMDRadeonX4000	1.5.1
com.apple.iokit.IOBluetoothSerialManager	5.0.5f1
com.apple.Dont_Steal_Mac_OS_X	7.0.0
com.apple.driver.AppleIntelHD5000Graphics	10.2.5
com.apple.driver.AppleLPC	3.1
com.apple.kext.AMD7000Controller	1.5.1
com.apple.driver.AppleCameraInterface	5.60.0
com.apple.driver.AppleHV	1
com.apple.driver.AppleOSXWatchdog	1
com.apple.iokit.BroadcomBluetooth20703USBTransport	5.0.5f1
com.apple.driver.AppleMCCSControl	1.3.4
com.apple.driver.AppleSMCLMU	208
com.apple.driver.AppleMuxControl	3.14.49
com.apple.driver.AppleIntelSlowAdaptiveClocking	4.0.0
com.apple.driver.AppleIntelFramebufferAzul	10.2.5
com.apple.driver.AppleThunderboltIP	3.0.8
com.apple.driver.AppleUSBCardReader	404.50.6
com.apple.driver.AppleTopCaseHIDEventDriver	114
com.apple.driver.AppleUSBTopCaseDriver	114
com.apple.iokit.IOAHCIBlockStorage	295.20.1
com.apple.driver.AirPort.Brcm4360	1150.12.1a1
com.apple.driver.AppleAHCIPort	326.60.1
com.apple.AppleFSCompression.AppleFSCompressionTypeDataless	1.0.0d1
com.apple.AppleFSCompression.AppleFSCompressionTypeZlib	1.0.0
com.apple.BootCache	40
com.apple.filesystems.hfs.kext	366.70.1
com.apple.iokit.AppleBCM5701Ethernet	10.2.10
com.apple.driver.AppleSmartBatteryManager	161.0.0
com.apple.driver.AppleACPIButtons	5.0
com.apple.driver.AppleRTC	2.0
com.apple.driver.AppleHPET	1.8
com.apple.driver.AppleSMBIOS	2.1
com.apple.driver.AppleACPIEC	5.0
com.apple.driver.AppleAPIC	1.7
com.apple.nke.applicationfirewall	172
com.apple.security.quarantine	3
com.apple.security.TMSafetyNet	8
com.apple.driver.IOBluetoothHIDDriver	5.0.5f1
com.apple.kext.triggers	1.0
com.apple.driver.DspFuncLib	279.48
com.apple.kext.OSvKernDSPLib	525
com.apple.iokit.IOSerialFamily	11
com.apple.driver.AppleSSE	1.0
com.apple.iokit.IOSurface	159.9
com.apple.kext.AMDSupport	1.5.1
com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport	5.0.5f1
com.apple.iokit.IOBluetoothHostControllerUSBTransport	5.0.5f1
com.apple.iokit.IOBluetoothHostControllerTransport	5.0.5f1
com.apple.iokit.IOBluetoothFamily	5.0.5f1
com.apple.driver.AppleHDAController	279.48
com.apple.iokit.IOHDAFamily	279.48
com.apple.iokit.IOAudioFamily	205.15
com.apple.vecLib.kext	1.2.0
com.apple.driver.AppleSMBusController	1.0.18d1
com.apple.driver.X86PlatformPlugin	1.0.0
com.apple.driver.IOPlatformPluginFamily	6.0.0d8
com.apple.driver.AppleBacklightExpert	1.1.0
com.apple.iokit.IONDRVSupport	516.1
com.apple.driver.AppleGraphicsControl	3.14.49
com.apple.iokit.IOSlowAdaptiveClockingFamily	1.0.0
com.apple.AppleGraphicsDeviceControl	3.14.49
com.apple.iokit.IOAcceleratorFamily2	311.14
com.apple.iokit.IOGraphicsFamily	515.3
com.apple.driver.AppleSMC	3.1.9
com.apple.iokit.IOSCSIBlockCommandsDevice	394.50.1
com.apple.iokit.IOUSBMassStorageDriver	131.60.1
com.apple.iokit.IOSCSIArchitectureModelFamily	394.50.1
com.apple.driver.usb.AppleUSBHub	1.1
com.apple.driver.AppleHIDKeyboard	199
com.apple.driver.AppleMultitouchDriver	368.16
com.apple.driver.AppleInputDeviceSupport	76.7
com.apple.driver.usb.IOUSBHostHIDDevice	1.1
com.apple.driver.usb.networking	5.0.0
com.apple.driver.usb.AppleUSBHostCompositeDevice	1.1
com.apple.driver.CoreStorage	540.30.1
com.apple.iokit.IO80211Family	1200.12.2
com.apple.driver.corecapture	1.0.4
com.apple.driver.usb.AppleUSBXHCIPCI	1.1
com.apple.driver.usb.AppleUSBXHCI	1.1
com.apple.iokit.IOAHCIFamily	288
com.apple.driver.AppleThunderboltDPInAdapter	5.0.2
com.apple.driver.AppleThunderboltDPAdapterFamily	5.0.2
com.apple.driver.AppleThunderboltPCIUpAdapter	2.1.3
com.apple.driver.AppleThunderboltPCIDownAdapter	2.1.3
com.apple.filesystems.hfs.encodings.kext	1
com.apple.iokit.IOEthernetAVBController	1.0.3b4
com.apple.driver.mDNSOffloadUserClient	1.0.1b8
com.apple.iokit.IONetworkingFamily	3.2
com.apple.driver.AppleThunderboltNHI	4.5.4
com.apple.iokit.IOThunderboltFamily	6.5.7
com.apple.driver.usb.AppleUSBHostPacketFilter	1.0
com.apple.iokit.IOUSBFamily	900.4.1
com.apple.driver.AppleUSBHostMergeProperties	1.1
com.apple.driver.AppleEFINVRAM	2.1
com.apple.driver.AppleEFIRuntime	2.1
com.apple.iokit.IOHIDFamily	2.0.0
com.apple.iokit.IOSMBusFamily	1.1
com.apple.security.sandbox	300.0
com.apple.kext.AppleMatch	1.0.0d1
com.apple.driver.AppleKeyStore	2
com.apple.driver.AppleMobileFileIntegrity	1.0.5
com.apple.driver.AppleCredentialManager	1.0
com.apple.driver.KernelRelayHost	1
com.apple.iokit.IOUSBHostFamily	1.1
com.apple.driver.AppleBusPowerController	1.0
com.apple.driver.DiskImages	444.50.16
com.apple.iokit.IOStorageFamily	2.1
com.apple.iokit.IOReportFamily	31
com.apple.driver.AppleFDEKeyStore	28.30
com.apple.driver.AppleACPIPlatform	5.0
com.apple.iokit.IOPCIFamily	2.9
com.apple.iokit.IOACPIFamily	1.4
com.apple.kec.pthread	1
com.apple.kec.corecrypto	1.0
com.apple.kec.Libm	1
Model: MacBookPro11,5, BootROM MBP114.0172.B25, 4 processors, Intel Core i7, 2.5 GHz, 16 GB, SMC 2.30f2
Graphics: AMD Radeon R9 M370X, AMD Radeon R9 M370X, PCIe, 2048 MB
Graphics: Intel Iris Pro, Intel Iris Pro, Built-In
Memory Module: BANK 0/DIMM0, 8 GB, DDR3, 1600 MHz, 0x802C, 0x31364B544631473634485A2D314736453120
Memory Module: BANK 1/DIMM0, 8 GB, DDR3, 1600 MHz, 0x802C, 0x31364B544631473634485A2D314736453120
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x152), Broadcom BCM43xx 1.0 (7.21.171.130.1a1)
Bluetooth: Version 5.0.5f1, 3 services, 27 devices, 1 incoming serial ports
Network Service: Thunderbolt Ethernet, Ethernet, en4
Network Service: Wi-Fi, AirPort, en0
PCI Card: Apple 57762-A0, Ethernet Controller, Thunderbolt@195,0,0
Serial ATA Device: APPLE SSD SM0512G, 500.28 GB
USB Device: USB 3.0 Bus
USB Device: Card Reader
USB Device: Hub
USB Device: Touro Mobile 3.0
USB Device: Apple Internal Keyboard / Trackpad
USB Device: Bluetooth USB Host Controller
USB Device: Hub
USB Device: Keyboard Hub
USB Device: Apple Keyboard
Thunderbolt Bus: MacBook Pro, Apple Inc., 27.1
Thunderbolt Device: Thunderbolt to Gigabit Ethernet Adapter, Apple Inc., 3, 5.5

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/61f09f37c6d4a16378cf7de73a94bf2562a73232

commit 61f09f37c6d4a16378cf7de73a94bf2562a73232
Author: Robert Sesek <rsesek@chromium.org>
Date: Thu Aug 24 22:32:56 2017

[Mac] Implement WaitableEvent::WaitMany with a kqueue on 10.12+.

The current implementation using Mach port sets may cause system instability
on macOS 10.11+. The kqueue implementation does not work until 10.12, so this
leaves 10.11 potentially still affected. 10.9, 10.10, 10.12, and 10.13 are
okay after this change.

Bug:  756102 
Bug: 681167
Change-Id: I031437cf414c71863c59d0726f8fdf7e4810a365
Reviewed-on: https://chromium-review.googlesource.com/624188
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#497219}
[modify] https://crrev.com/61f09f37c6d4a16378cf7de73a94bf2562a73232/base/synchronization/waitable_event_mac.cc

Issue 759424 has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5cd8eef498e28e1aacb9109645c001bbbfe1bc26

commit 5cd8eef498e28e1aacb9109645c001bbbfe1bc26
Author: Robert Sesek <rsesek@chromium.org>
Date: Mon Aug 28 19:51:25 2017

[Mac] A potential fix for WaitableEvent::WaitMany on macOS 10.11.

This avoids the creation of port sets, which could cause system instability.
Instead, this uses libdispatch sources to watch the event ports.

Bug:  756102 
Bug: 681167
Change-Id: Ib6fe015802dbe988d740b8319dd4a92601f17b26
Reviewed-on: https://chromium-review.googlesource.com/634924
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#497850}
[modify] https://crrev.com/5cd8eef498e28e1aacb9109645c001bbbfe1bc26/base/synchronization/waitable_event_mac.cc

Can you comment (in the code too) on why we're using libdispatch for 10.11 and kqueues on 10.12, rather than libdispatch which would work on both? Is it a speed issue?

 Issue 755623  has been merged into this issue.

Re: #33: Yes, I will do that. The CL didn't because I'm actually not sure the kqueue implementation will stick. The previous implementation of WaitableEvent used kqueue, but it had to be abandoned because users kept hitting ENFILE. So I may make 10.12 use the dispatch path, but I'm currently observing crash data.

M62 is branching today, can we have the latest update on this issue?

This should be fixed, but because we can't collect panic reports, we need user confirmation. The panic issue should be resolved on all OSes after 62.0.3199.0, and resolved on 10.12 after 62.0.3196.0.

I will watch a lot of videos on canary this weekend and report back if I experience the same kernel panic next week.

Let me report that OS crashes stoped on my environments.
MacPro and MacBookPro (2016 13' touch bar)
Both with the latest macOS (10.12.6).

Update for #35: Still waiting to see how the kevent does on a larger population of users, but we probably won't want to switch to libdispatch on 10.12 because it is slower and triggered some performance alerts ( issue 760566 ).

Just to update, this is marked as Beta blocker and M-62 will go to Beta in week's time.

zmo@: Can we get an update on this and confirmation if any such kernel panic was encountered again.

For what it's worth, this was happening multiple times per day to me and this has stopped in recent dev channel updates. Per comment 37, this may be fixed but we just don't have data to prove it.

Re-assigning to mark@chromium.org since rsesek is out.

No, it no longer happened on my Mac.  I re-watched all three Matrix movies this weekend, and no panic.

Seems like the issue is resolved. If yes, please remove the RBB label.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-62; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-62 label, otherwise remove Merge-TBD label. Thanks.

62.0.3199.0 had the fix for all platforms. 62 branched at 3202 so we're in the clear.