1) This is a regression crash seen from 54.0.2840.59, spiked in latest stable #55.0.2883.95 and crashes are also seen in latest beta #56.0.2924.67.

2) Currently its a top #11 browser crasher having 5 crashes from 5 unique client Ids.

3) Crashes are seen on latest M58, M57, M56 and M55 as below.

   58.0.2990.0	0.12%	1	-- Latest Canary
   57.0.2986.0	0.12%	1	-- Latest Dev
   56.0.2924.67	0.58%	5	-- Latest Beta
   55.0.2883.95	69.45%	598	-- Latest Stable

4) Link to list of builds where crashes are seen:
https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Mac%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BCocoa%20Zombie%5D%20-%5BRenderWidgetHostViewCocoa%20candidateListTouchBarItem%5D%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,productversion:1000

5) Unable to find any possible suspect from the above stack trace.

Note: It might be related to Issue id: 526263 or Issue id: 520706.

Could anyone from the dev team please have a look into this issue.

Thanks...!!

Users experienced this crash on the following builds:

Mac Beta 56.0.2924.67 -  0.12 CPM, 5 reports, 5 clients (signature [Cocoa Zombie] -[RenderWidgetHostViewCocoa candidateListTouchBarItem])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

[mac triage] Touchbar related. Probably 10.12 + Touchbar macbook specific

zombieZombie <RenderWidgetHostViewCocoa: 0x7fab8c453920> received -candidateListTouchBarItem (via -respondsToSelector:) in 	-[NSTextInputContext candidateListTouchBarItem]

zombie_dealloc_bt0x10c5aef87 0x7fff76c326e9 0x7fff76c31102 0x10c5049b8 0x10b243558 0x7fff8ddd4c49 0x7fff8ddcfe60 0x7fff7907f106 0x7fff7aae5f13 0x10bbb2ebf 0x10bba549a 0x10bbb28d4 0x7fff790de8d1 0x7fff790bfc6c 0x7fff790bf156 0x7fff790beb54 0x7fff78649acc 0x7fff78649901

(robert: I tried plugging that into go/crsym and it didn't work .. just gave blank output - maybe I'm holding it wrong.)

This is probably an Apple bug, by we may need to find a repro/workaround.

Symbolized zombie_dealloc_bt (I did this by using the "Crash Key" symbolizer in crsym/ and using the initial report crash ID and "zombie_dealloc_bt" as the key to symbolize). Obviously this isn't an interesting stack, though:

0x02252f87 [Google Chrome Framework -	 algorithm:714] (anonymous namespace)::ZombieDealloc(objc_object*, objc_selector*)
0x0003a6e9 [AppKit +	 0x3a6e9] -[NSResponder dealloc]
0x00039102 [AppKit +	 0x39102] -[NSView dealloc]
0x021a89b8 [Google Chrome Framework -	 base_view.mm:32] -[BaseView dealloc]
0x00ee7558 [Google Chrome Framework -	 render_widget_host_view_mac.mm:1782] -[RenderWidgetHostViewCocoa dealloc]
0x0000ec49 [libobjc.A.dylib +	 0xec49] objc_object::sidetable_release(bool)
0x00009e60 [libobjc.A.dylib +	 0x9e60] (anonymous namespace)::AutoreleasePoolPage::pop(void*)
0x00045106 [CoreFoundation +	 0x45106] _CFAutoreleasePoolPop
0x00016f13 [Foundation +	 0x16f13] -[NSAutoreleasePool drain]
0x01856ebf [Google Chrome Framework -	 message_pump_mac.mm:89] base::MessagePumpCFRunLoopBase::RunWork()
0x0184949a [Google Chrome Framework +	 0x184949a] base::mac::CallWithEHFrame(void () block_pointer)
0x018568d4 [Google Chrome Framework -	 message_pump_mac.mm:281] base::MessagePumpCFRunLoopBase::RunWorkSource(void*)
0x000a48d1 [CoreFoundation +	 0xa48d1] __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
0x00085c6c [CoreFoundation +	 0x85c6c] __CFRunLoopDoSources0
0x00085156 [CoreFoundation +	 0x85156] __CFRunLoopRun
0x00084b54 [CoreFoundation +	 0x84b54] CFRunLoopRunSpecific
0x00030acc [HIToolbox +	 0x30acc] RunCurrentEventLoopInMode
0x00030901 [HIToolbox +	 0x30901] ReceiveNextEventCommon

+spqchan who is working on touchBar stuff

Users experienced this crash on the following builds:

Mac Canary 58.0.2993.0 -  0.62 CPM, 1 reports, 1 clients (signature [Cocoa Zombie] -[RenderWidgetHostViewCocoa candidateListTouchBarItem])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Users experienced this crash on the following builds:

Mac Dev 57.0.2987.19 -  0.24 CPM, 2 reports, 2 clients (signature [Cocoa Zombie] -[RenderWidgetHostViewCocoa candidateListTouchBarItem])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Users experienced this crash on the following builds:

Mac Canary 59.0.3032.0 -  0.50 CPM, 3 reports, 3 clients (signature [Cocoa Zombie] -[RenderWidgetHostViewCocoa candidateListTouchBarItem])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

I ran into this crasher last week (in 58.0.3029.54, Beta channel). Is this crasher related to Touch Bar support? If so, will it happen with the Touch Bar code turned off?

This is probably not caused by the Touch Bar support, since it's found before support was implemented 

Users experienced this crash on the following builds:

Mac Canary 60.0.3083.0 -  0.30 CPM, 1 reports, 1 clients (signature [Cocoa Zombie] -[RenderWidgetHostViewCocoa candidateListTouchBarItem])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Just to update, latest crash rates on all channels are as below:
This crash not seen on latest Canary & Dev.
	
59.0.3071.36	0.01%	2	-Beta
58.0.3029.96	1.12%	169	-Stable

Link to the list of builds:
----------------------------
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BCocoa%20Zombie%5D%20-%5BRenderWidgetHostViewCocoa%20candidateListTouchBarItem%5D%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,productversion:1000

Thank You!

Issue 720235 has been merged into this issue.

I got this crash on a prev-gen non-TouchBar MBP.
This bit me twice when I was trying to close a Google Hangouts chat (using the Hangouts Chrome extension)

Here are two of my Crash IDs:
crash/e454d080d0000000 crash/b60ae280d0000000

This crash has been around for a while, can we have a fix soon( Ranks #3 in current stable-58.0.3029.110). Looping to sheriff to expedite the fix.

I'm investigating this

Re: c#1, crashes are seen in M55, but no touch bar code had landed in Chrome at that time (M55 branched in early October). So it doesn't seem like this is related to any changes spqchan@ has made.

I suspect this is similar, but the inverse of,  issue 667274 . RenderWidgetHostViewCocoa  is a NSTextInputClient, which looks implicated by -[NSTextInputContext deactivate]. Perhaps it's keeping an unretained list of NSTextInputClients and we zombie out because of that.

Hey Sarah - just double checking since this is in the sheriff queue. Are you still investigating this?

yes

Just to update, latest crash rates on all channels are as below:
This crash not seen on latest canary,Dev & Beta.

58.0.3029.110	11.78%	2213	-Stable
58.0.3029.96	4.43%	832	
58.0.3029.81	4.42%	831	
58.0.3029.68	0.07%	13	

Link to the list of builds:
----------------------------
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BCocoa%20Zombie%5D%20-%5BRenderWidgetHostViewCocoa%20candidateListTouchBarItem%5D%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#-property-selector,samplereports:5,productversion:1000,magicsignature

Thank You!

Removing from sheriff queue since owner is actively investigating.

I'm seeing this frequently (approx daily) and it's super productivity destroying.

This crash is caused when I close the Hangouts extension window. It seems to me that the problem is related to displays of different density. I have an HDPI display on my laptop and two normal DPI external displays.

My observations are that if Hangouts is open when normal DPI displays are attached, the window doesn't re-rendered on the normal display resolution. I've actually observed that clicks on the normal DPI window are off by a factor pixels. E.g. clicking roughly at 200,200 results in a click at 100,100 (or vice versa).

I can usually work around this crash by first moving the Hangouts window to my HDPI display, then closing it, then opening it again and all is fine.

My intuition tells me it's something to do with the multi DPI code and extension windows not being properly updated on display configuration changes.

Crash ID d1fa68aa-2a5d-4019-8d13-57b00df16795 (Server ID: 8421731e80000000)
Crash report captured on Monday, May 1, 2017 at 3:14:48 PM, uploaded on Monday, May 1, 2017 at 3:14:49 PM

Crash ID 6179e214-f8f0-4276-a8b8-c7653f2ad862 (Server ID: 2950e6b350000000)
Crash report captured on Wednesday, May 3, 2017 at 5:42:35 PM, uploaded on Wednesday, May 3, 2017 at 5:42:35 PM

Crash ID 6af0aa23-5d0c-487e-9870-b1386be51c58 (Server ID: 19505e9e80000000)
Crash report captured on Thursday, May 4, 2017 at 3:03:46 PM, uploaded on Thursday, May 4, 2017 at 3:03:46 PM

Crash ID 361edb5c-0ee8-4935-8537-eed061da8d04 (Server ID: 0989c87e80000000)
Crash report captured on Monday, May 8, 2017 at 11:55:00 AM, uploaded on Monday, May 8, 2017 at 11:55:00 AM

Crash ID 7405a0db-588d-4072-9978-736c9eacf849 (Server ID: 2456b46f50000000)
Crash report captured on Monday, May 8, 2017 at 6:35:50 PM, uploaded on Monday, May 8, 2017 at 6:35:51 PM

Crash ID 5459163d-ca6e-40f6-91c6-3a077ed81611 (Server ID: 0b7d8cf640000000)
Crash report captured on Thursday, May 11, 2017 at 3:21:20 PM, uploaded on Thursday, May 11, 2017 at 3:21:21 PM

Crash ID f82b5c6b-8412-4e05-b409-99f3997a9646 (Server ID: 9a48258ea8000000)
Crash report captured on Monday, May 15, 2017 at 11:44:28 AM, uploaded on Monday, May 15, 2017 at 11:44:29 AM

Crash ID d4276380-5ea6-44e6-9a5a-d8b5f1d01791 (Server ID: 6617e3ae98000000)
Crash report captured on Wednesday, June 7, 2017 at 1:05:13 PM, uploaded on Wednesday, June 7, 2017 at 1:05:13 PM

Crash ID ec2adab1-bc23-4d94-95ee-695c56a0d4f7 (Server ID: d2f0d965f0000000)
Crash report captured on Friday, June 9, 2017 at 11:49:55 AM, uploaded on Friday, June 9, 2017 at 11:49:56 AM

Crash ID 0b3f40b7-faf4-4887-80da-b97bbb66dd2a (Server ID: 5007fb93f0000000)
Crash report captured on Monday, June 12, 2017 at 2:15:56 PM, uploaded on Monday, June 12, 2017 at 2:15:56 PM

Users experienced this crash on the following builds:

Mac Canary 61.0.3128.0 -  0.25 CPM, 1 reports, 1 clients (signature [Cocoa Zombie] -[RenderWidgetHostViewCocoa candidateListTouchBarItem])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

It happens to me multiple times a day.

> It seems to me that the problem is related to displays of different density.
> I have an HDPI display on my laptop and two normal DPI external displays.

It crashes for me even when I don't connect external monitors at all.

Just to update, latest crash rates on all channels are as below:
This crash not seen on latest canary,Dev & Beta.

59.0.3071.115	1.13%	283		-Stable
	

Link to the list of builds:
----------------------------
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BCocoa%20Zombie%5D%20-%5BRenderWidgetHostViewCocoa%20candidateListTouchBarItem%5D%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#-property-selector,samplereports:5,productversion:1000,magicsignature

Thank You!

Crash ID d2eaa809-fe09-4647-a64e-da841afb5a08 (Server ID: 9c02828108000000)
Crash report captured on Friday, June 30, 2017 at 2:15:26 PM, uploaded on Friday, June 30, 2017 at 2:15:27 PM

No external displays involved this time.

I think it has to do with multi-profile.
I've used only my personal profile over the long weekend and it hasn't crashed once.

I've been using both my personal and work profile today and it has already crashed twice:
d6887e6d-8c25-4ba2-b1db-002b546d995d
b56e9dbe-ec5d-4389-8438-a7eab4b2475f

Both of my profiles are signed in to Hangouts using this extension:
https://chrome.google.com/webstore/detail/google-hangouts/ljclpkphhpbpinifbeabbhlfddcpfdde

Thanks for the heads up, I'll give that a try to replicate it

One more data point: I usually keep my personal/work profiles on different Desktops and often switch back and forth between them.

timurrrr@ - what are the server IDs for the crashes, and in which version of Chrome?

Server ID: 176c0fde40000000
Server ID: 03b45fcf38000000

59.0.3071.115 (Official Build) (64-bit)
Revision	3cf8514bb1239453fd15ff1f7efee389ac9df8ba-refs/branch-heads/3071@{#820}

Crash ID a7be5f81-f329-45f9-98bb-a2c478cac7b0 (Server ID: 08af1b8268000000)
Crash report captured on Thursday, July 13, 2017 at 11:43:48 AM, uploaded on Thursday, July 13, 2017 at 11:43:49 AM

I too am using multi-profile, across multiple virtual desktops.

Same here. I use 3 profiles across 3 virtual desktops.

I get a crash every 2 days or so.

Recent ones:
Crash ID c6aee20d-491f-4d42-8daa-94b83b6c1363 (Server ID: c1a8a6e088000000)
Crash ID dfb0f93f-9291-452f-9b51-fff2bcf31c89 (Server ID: 2351648268000000)
Crash ID 664bb272-1b91-4b96-846d-2dd6f4018899 (Server ID: 47e2433e40000000)

Crash ID 905a2b8d-9f8a-47f2-a593-a39cb5a8a69d (Server ID: c8d3c57e40000000)
Crash report captured on Monday, July 17, 2017 at 10:45:14 AM, uploaded on Monday, July 17, 2017 at 10:45:17 AM

Any update on this bug? It has been about two months since the status was set to "started".

The issue is that NSTextContextClient is being deallocated before the NSTextContextContext does. Why and where is happening? That's being investigated

Not sure which NSTextContextClient it is. I initially suspected RenderWidgetHostViewCocoa but it looks like it can also be anything else that interacts with the text system like the omnibox.

From the comments it looks like the issue might also be tied with the hangouts extension. If that's not the case, it's probably not the omnibox.

An idea I've toying with is resigning the first responder status when the RenderWidgetHostViewCocoa or omnibox gets deallocated. That probably won't fix it but it's probably worth a try

Is this reproducible under ASan? It would usually tell you the deallocation stack if you're using something after it is deallocated.

I haven't had luck with reproducing this issue

If it's reproducible at all under ASan, it may be much easier to repro it
under ASan that without it.

Thanks for the heads up. Unfortunately, there's still no luck but I think I found something in the RenderWidgetHostView. Question: do the crash occur when you navigate?

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

commit 4f643d41b02091e79ddf89193accc008c0da3dc9
Author: spqchan <spqchan@chromium.org>
Date: Wed Jul 26 17:00:18 2017

Fix for RenderWidgetHostViewCocoa crash

RenderWidgetHostViewCocoa's NSTextInputContext object
might be around as the currentInputContext when the 
RenderWidgetHostView is already deallocated. This
causes a crash. 

To fix this issue, update the currentInputContext
before it gets deallocated.

Bug:  684388 
Change-Id: Ia902905f23e08a9d5d2d5129a1fd7bb98bd352b8
Reviewed-on: https://chromium-review.googlesource.com/585865
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Sarah Chan <spqchan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#489676}
[modify] https://crrev.com/4f643d41b02091e79ddf89193accc008c0da3dc9/content/browser/renderer_host/render_widget_host_view_mac.mm

This time the Hangouts extension had been open and closed all day, but when I woke my laptop up (with external displays connected) and closed the Hangouts window my browser died.

This time I accidentally close the tab with the restore button and had to manually restore my state. Is there any way to bring that restore button back if you accidentally close the tab?

Crash ID 890f46c9-8956-4e0b-8683-58fcc74c9043 (Server ID: 91051acd04000000)
Crash report captured on Tuesday, August 1, 2017 at 7:31:15 PM, uploaded on Tuesday, August 1, 2017 at 7:31:16 PM

Issue 748224 has been merged into this issue.

Uploaded Crash Report ID 10c5c2c735de6c09 (Local Crash ID: f19a98c8-3457-4927-a18f-da45942f5fd0)
Crash report captured on Friday, August 18, 2017 at 5:20:55 PM, uploaded on Friday, August 18, 2017 at 5:20:56 PM

Issue 759086 has been merged into this issue.

Uploaded Crash Report ID 0febf199664a6ea3 (Local Crash ID: 33250161-09c4-414e-b391-5303526b42e4)
Crash report captured on Thursday, September 7, 2017 at 10:53:42 AM, uploaded on Thursday, September 7, 2017 at 10:53:50 AM

No external displays involved in this one.

Uploaded Crash Report ID 29c61e7a21a28f96 (Local Crash ID: acb29130-5fc9-42b8-9b17-bfc04c779b09)
Crash report captured on Friday, September 8, 2017 at 4:00:49 PM, uploaded on Friday, September 8, 2017 at 4:00:49 PM

This may be an AppKit bug. If so, I'll go ahead and file a rdar for this.

The labels indicate this crasher first appeared in M56, which corresponds to the debut of Touch Bar Macs and also predates our Touch Bar code.

I see NSAutomaticFocusRing in the backtrace. I don't believe the web content uses native focus ring machinery so that suggests a control in the top chrome, a secondary UI dialog, or the downloads bar.

I also see NSPostActiveFirstResponderChanged in the backtrace, and the zombie is a RenderWidgetHostViewCocoa. All together it seems like a native Cocoa control has first responder status at the time a browser window gets closed. The RenderWidgetHostViewCocoa gets freed before the Cocoa window has been completely torn down. It seems like perhaps the RenderWidgetHostViewCocoa has been freed but still remains in the responder chain and so is asked if it responds to -candidateListTouchBarItem.

From my investigations, [NSTextInputContext currentInputContext] is pointing to RenderWidgetHostViewCocoa's textInputContext when RWHVC becomes the first responder. candidateListTouchBarItem is being called from the currentInputContext

When RWHVC loses the first responder status, [NSTextInputContext currentInputContext] should no longer point to its textInputContext. It looks like it's still pointing to it after RWHVC is deallocated

I introduced a CL in #47 that would resign RWHVC's first responder status (and hopefully update the currentInputContext] and call [NSApp updateWindows] which will could also update the currentInputContext. It looks like doing that doesn't work.

It looks like the bug is caused by the Hangouts extension so the Hangouts window might be doing something weird.

Uploaded Crash Report ID 64c4a9f4b3f956c3 (Local Crash ID: 3e8ab7cb-d638-4c6e-89d2-e675314243fb)
Crash report captured on Wednesday, September 20, 2017 at 10:58:53 AM, uploaded on Wednesday, September 20, 2017 at 10:58:55 AM

So what is the next step on this? And why do you believe it's related to HangOuts?

Uploaded Crash Report ID c2f7a68a927c64f2 (Local Crash ID: 1ac5521d-fa1e-4362-a6ac-0d11250c3e49)
Crash report captured on Wednesday, September 27, 2017 at 5:05:35 PM, uploaded on Wednesday, September 27, 2017 at 5:05:35 PM

@shrike for me this crash occurs when I close the Hangouts extension window. AFAIK it has not often (ever?) happened to me in any other circumstance.

Uploaded Crash Report ID 954e06bfe1e53b47 (Local Crash ID: 5bd4f224-2b29-4272-96d8-cf1585356005)
Crash report captured on Thursday, September 28, 2017 at 1:10:28 PM, uploaded on Thursday, September 28, 2017 at 1:10:29 PM

Uploaded Crash Report ID 7280a1ddd8ef2dfb (Local Crash ID: 96647b36-3499-427a-906f-109c72e5b75e)
Crash report captured on Thursday, September 28, 2017 at 5:42:54 PM, uploaded on Thursday, September 28, 2017 at 5:42:55 PM

Uploaded Crash Report ID 46710bad560d2ea8 (Local Crash ID: 2d37c9f3-d9a7-4831-8665-0c1ecafcf593)
Crash report captured on Tuesday, October 3, 2017 at 7:32:08 PM, uploaded on Tuesday, October 3, 2017 at 7:32:09 PM

Issue 750789 has been merged into this issue.

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

commit bea22ff26931e94fdeb59e98a508ca4222c5b776
Author: spqchan <spqchan@chromium.org>
Date: Sat Oct 21 00:00:11 2017

[Mac] Add Crash Key for RenderWidgetHostViewMac Crash

The crash key will be used to check if
RenderWidgetHostViewMac is still being held by AppKit
after it's deallocated.

Bug:  684388 
Change-Id: Ie0cbf15d94e7d9b204bd7da4cc0307b24c19a01c
Reviewed-on: https://chromium-review.googlesource.com/729566
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Sarah Chan <spqchan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510619}
[modify] https://crrev.com/bea22ff26931e94fdeb59e98a508ca4222c5b776/chrome/common/crash_keys.cc
[modify] https://crrev.com/bea22ff26931e94fdeb59e98a508ca4222c5b776/content/browser/renderer_host/render_widget_host_view_mac.mm

No crashes are observed post chrome version #62.0.3167.0. Hence, adding TE-Verified labels.

Link to the list of builds:
============================
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BCocoa%20Zombie%5D%20-%5BRenderWidgetHostViewCocoa%20candidateListTouchBarItem%5D%27%20AND%20product.name%3D%27Chrome_Mac%27&sql_dialect=dremelsql&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#productversion:1000

Thanks...!