1585870 - Force Quit doesn't generate a crash report when Firefox hangs

Status: NEW

(Toolkit :: Crash Reporting, defect, P3)

Description

[Oleksii Segeda [:Sound]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

1. Make Firefox unresponsive. (for example, by opening crashsafari.com and leaving it running for 3-5 minutes. )
2. Force Quite it manually or wait until OS offers to kill it.

Actual results:

Crash report was not generated (about:crashes). The OS crash dialog popped up asking to send this crash info to Apple.

Expected results:

Crash report should be generated

Comment 1

[Gabriele Svelto [:gsvelto]]

Confirmed however I don't know if it's possible to fix this.

Comment 2

[Gabriele Svelto [:gsvelto]]

Steven, do you know if it's possible to override the macOS crash reporter when force quitting?

Comment 3

[Steven Michaud [:smichaud] (Retired)]

I don't know. I'll try to find out, but I won't have time to work on this bug until sometime in January.

This bug is an excellent testcase for HookCase. I'd use at least two hook libraries -- one to hook Firefox's crash and abort handlers (to see if they're ever called), and to provide a way to hang the Firefox main thread on demand; the others to hook whatever code Apple runs to force quit an application (starting with whatever puts up the Force Quit dialog).

It may turn out there's nothing we can do. But it's a shame to conclude that before looking.

I'll tentatively assign this bug to myself.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

Just in case someone else also thinks of it:

The crash and abort handlers run in-process. But the crash handler runs on a secondary thread, and the abort handler runs on whatever thread system code uses to send an abort signal. So the fact that these handlers run in-process doesn't guarantee that we won't be able to find a fix/workaround for this bug.

Comment 5

[Oleksii Segeda [:Sound]]

This might sound stupid, but wouldn't SIGTERM listener in the main process fix this?

Comment 6

[Steven Michaud [:smichaud] (Retired)]

wouldn't SIGTERM listener in the main process fix this?

Yes, it might. But then why isn't it working already? And what if the OS is trying to call it on the main thread, while the main thread is hung?

If at all possible, we need to understand this problem from both sides -- Firefox's and Apple's. That will involve a certain amount of digging.

Comment 7

[Gabriele Svelto [:gsvelto]]

Thanks Steven, very appreciated if you can work on this. Regarding handling SIGTERM we should probably check how that works on macOS. Right now breakpad's signal handler on macOS handles just SIGABRT but that's because we intercept the vast majority of the actual exceptions via a mach port using task_set_exception_ports() instead.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 9

[Marco Castelluccio [:marco]]

Sorry, there was a problem with the detection of inactive users. There was no action for a while so I won't revert the change, but feel free to reassign it to yourself in case you're still planning to work on this.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

I'd forgotten about this bug. NI-ing myself to remind me.

I probably won't get to it soon, and I may never do so. So I won't reassign it to myself (at least yet).

I also have a bunch of Mozilla bugs assigned to me that are left over from when I was a Mozilla employee. I'll never get to those. I neglected to take my name off them when I retired. I'll do that now (in small batches).

Comment 11

[Suhaib Mujahid [:suhaib]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

Having this reassigned to me will serve as a good enough reminder, once I clear out the assignments I'll definitely never get to.