Bug 1722827 Comment 23 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Leo, do please try `kill -6 [firefox-pid]`. But that's not actually a definitive test, because Breakpad (Firefox's crash handler) uses a signal handler to catch this kind of crash. To test the main functionality (which catches Mach exceptions), one needs to create a try build that will, say, do a NULL dereference on demand. I'll do one in the next few hours, and ask you to try that.

Yes, but 1724215 may explain what's going on here. But it's a pretty far-out hypothesis. We should as least try to eliminate other possibilities.
Leo, do please try `kill -6 [firefox-pid]`. But that's not actually a definitive test, because Breakpad (Firefox's crash handler) uses a signal handler to catch this kind of crash. To test the main functionality (which catches Mach exceptions), one needs to create a try build that will, say, do a NULL dereference on demand. I'll do one in the next few hours, and ask you to try that.

Yes, bug 1724215 may explain what's going on here. But it's a pretty far-out hypothesis. We should as least try to eliminate other possibilities.
Leo, do please try `kill -6 [firefox-pid]`. But that's not actually a definitive test, because Breakpad (Firefox's crash handler) uses a signal handler to catch this kind of crash. To test the main functionality (which catches Mach exceptions), one needs to create a try build that will, say, do a NULL dereference on demand. I'll do one in the next few hours, and ask you to try that.

Yes, bug 1724215 may explain what's going on here. But it's a pretty far-out hypothesis. We should as least try to eliminate other possibilities.

Edit:

> Just please note that nightly currently cannot be used for long enough to get the crash information through the UI.

I hadn't thought of that. Sigh.

Back to Bug 1722827 Comment 23