Could this be addressed in any near future? We are missing a full picture on what's going on on Linux/Mac for Issue 647498

cc:pinkerton for macOS prioritization. -windows since we know it works there.

Is this something the crash team is looking into? Not having hang reports at all or for non-Windows platforms seems like a worrying blind spot.

replacing me with shrike@ for prioritization. 

sdy@ - any thoughts on effort needed to get this working on the Mac side?

What does the kill button do now, send SIGKILL? We can switch it to send one of these other signals.

https://chromium.googlesource.com/crashpad/crashpad/+/bf2c5155d28f4756a242ead9b6cac25d958e0a91/util/posix/signals.cc#27

Drawback: SIGKILL definitely kills, and these other signals can be caught and made to not kill. We could do something like “first click sends a core-generating signal, second click sends SIGKILL.” I think that this is what macOS’ command-option-escape killer does.

Other drawback: there are a limited number of signals to choose from. This isn’t such a big deal on macOS, because real crashes originating as hardware faults start out life as a Mach exception, and we record that and carry it all the way through with the crash report so that we can tell what they are. But on Linux, we’re stuck with signals, and a crash report for a process killed in the way I’m suggesting would be trickier to distinguish from one for which the kernel raised the signal in response to a hardware fault. It’s not impossible to distinguish, but I don’t know if Breakpad captures this information (Crashpad will) and I don’t think it’s surfaced anywhere on the crash server.

SIGQUIT is my choice for this (in large part because it’s not associated with any hardware cause).

Hi! Are there any updates on this? thanks!

Friendly ping