Stack trace for the crash id:
-----------------------------
Thread 17 (id: 0x1064) CRASHED [Simulated Exception @ 0x000007feec90fb3e ] MAGIC SIGNATURE THREAD
Stack Quality100%Show frame trust levels
0x000007feec90fb3e	(chrome_elf.dll -crashpad.cc:268 )	crash_reporter::DumpWithoutCrashing()
0x000007feec90ea26	(chrome_elf.dll -crashpad_win.cc:170 )	crash_reporter::internal::DumpProcessForHungInputThread(void *)
0x76f359cc	(KERNEL32.dll + 0x000159cc )	BaseThreadInitThunk
0x7716b980	(ntdll.dll + 0x0002b980 )	RtlUserThreadStart

Adding release blocker label for this issue.Please reduce priority or remove if not the case.

Thank You!

This is associated in the crash server with 'crash_reporter::DumpWithoutCrashing'. As per the crash server data this specific magic signature has spiked on the latest Windows canary 73.0.3630.0, reported 19 crashes from 18 clients so far.

Link to the list of the builds with the crashes:
=================================================
https://goto.google.com/bwgcn

Based on the crash server spike on canary considering below as the changelog:
===================================================================
https://chromium.googlesource.com/chromium/src/+log/73.0.3629.0..73.0.3630.0?pretty=fuller&n=10000

Suspecting: https://chromium-review.googlesource.com/c/chromium/src/+/1357941 for 'crashpad.cc:268' related change.

+jperaza@ for inputs.

This doesn't look related to the Crashpad CL. That CL should only affect Android.

DumpWithoutCrashing() here looks to be working as intended. It is triggering a crash dump in response to a hang.
https://cs.chromium.org/chromium/src/chrome/browser/hang_monitor/hang_crash_dump_win.cc?rcl=4f03013104e9848b0c0d6ca0c0fdbd2c30410395&l=19

As updated in C#3 the CL pointed in C#2 is unrelated as that affects Android but seeing only this as relevant in the regression range as this modified crashpad.cc.

Putting this into sheriff's queue as 'crash_reporter::DumpWithoutCrashing' is top crash on canary 73.0.3630.0 spiked on this version only.

Hi,

Re-bisected the above bug today on different machines and getting the same suspect as mentioned in the bug.

Change-Log:

https://chromium.googlesource.com/chromium/src/+log/b52ebdc80dde907896fdf8bafc231e30b348b30b..c3736ed68a7fc7f5d683bce471f926d56505027d

Thank You!

Just to update, there are no crashes seen with the magic signature 'crash_reporter::DumpWithoutCrashing' on the latest Windows canary 73.0.3632.0 live for 5 hrs so far.


aimana@: Could you please check this on the latest canary and confirm if this is still an issue for you. If yes, please attach crash id from there.

Removing blocker label, since this is not a straight/consistent (3/5) repro. 

DumpWithoutCrashing is called as part of hung-renderer reporting; if the tab itself crashed, then that will appear under an entirely separate crash report, with a different signature.  There are no other crash reports with the same client-Id, AFAICT, so we can't determine what the real crasher was.

Note that we should not see DumpWithoutCrashing reported in this case- the Crash server should be setting a Magic Signature of the form "[Hung renderer] ...".

Looking at the hung thread in the report, it is stuck in printing::PrintRenderFrameHelper::RequestPrintPreview, waiting for a reply to a synchronous IPC - we have two bugs filed for that signature, the latest being issue 903296.

If we expand the crash filter to _all_ reports which have a thread in printing::PrintRenderFrameHelper::RequestPrintPreview then we get an average of about 4000 reports per-day:
https://crash.corp.google.com/browse?q=EXISTS+%28SELECT+1+FROM+UNNEST%28thread%29+CROSS+JOIN+UNNEST%28StackTrace.StackFrame%29+WHERE+FunctionName%3D%27printing%3A%3APrintRenderFrameHelper%3A%3ARequestPrintPreview%28printing%3A%3APrintRenderFrameHelper%3A%3APrintPreviewRequestType%29%27%29+AND+stable_signature%3D%27crash_reporter%3A%3ADumpWithoutCrashing-0f153b79%27&stbtiq=&reportid=&index=0#0
These reports affect all platforms, but Windows is by far the most common.

Three-quarters of all reports also have a thread in DumpProcessForHungInputThread, indicating that these are hang reports (we have other uses for DumpWithoutCrashing).
https://crash.corp.google.com/browse?q=EXISTS+%28SELECT+1+FROM+UNNEST%28thread%29+CROSS+JOIN+UNNEST%28StackTrace.StackFrame%29+WHERE+FunctionName%3D%27printing%3A%3APrintRenderFrameHelper%3A%3ARequestPrintPreview%28printing%3A%3APrintRenderFrameHelper%3A%3APrintPreviewRequestType%29%27%29+AND+EXISTS+%28SELECT+1+FROM+UNNEST%28CrashedStackTrace.StackFrame%29+WHERE+FunctionName%3D%27crash_reporter%3A%3Ainternal%3A%3ADumpProcessForHungInputThread%28void+*%29%27%29#-propertyselector,samplereports,+productname:1000,-magicsignature:50,-magicsignature2:50,-stablesignature:50
These reports correspond to issue 903296 so I've followed-up there; we should fix this code path not to report bogus hangs!

Punting this back to aimana@ to repro and get a report-Id for the actual crash, rather than a renderer-hang report-Id. :)

On the crash server, I only see 1 crash listed for the client that sent the hung crash report. Not sure what happened to the actual crash.

Oh, hitting "exit page" results in a renderer kill.