With MOZ_CRASHREPORTER_SHUTDOWN environment variable set the browser should quit with a non 0 exit code
Categories
(Toolkit :: Startup and Profile System, enhancement, P5)
Tracking
()
Tracking | Status | |
---|---|---|
firefox102 | --- | fixed |
People
(Reporter: whimboo, Assigned: whimboo)
References
Details
Attachments
(1 file)
Comment 1•7 years ago
|
||
Updated•7 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
With bug 1675329 fixed, we should be able to exit Firefox with a different exit code now. Dave, what do you think which code would make sense?
Comment 3•4 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] (away 01/15 - 01/31) from comment #2)
With bug 1675329 fixed, we should be able to exit Firefox with a different exit code now. Dave, what do you think which code would make sense?
As I think the only person currently using it I'm going to say Nick should make a suggestion here.
Comment 4•4 years ago
|
||
(In reply to Dave Townsend [:mossop] from comment #3)
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] (away 01/15 - 01/31) from comment #2)
With bug 1675329 fixed, we should be able to exit Firefox with a different exit code now. Dave, what do you think which code would make sense?
As I think the only person currently using it I'm going to say Nick should make a suggestion here.
I have no strong opinions. For background tasks I settled on:
0 - success
2 - couldn't find background task with given name
3 - task threw an exception
I expect tasks themselves to exit with code 0 (success) or 1 (error) most frequently, hence no 1 in the harness.
In Henrik's use case I'd probably go with something >1 just so that it stands out a little bit more.
Assignee | ||
Comment 5•4 years ago
|
||
So when we call Services.startup.quit()
with Ci.nsIAppStartup.eForceQuit
we shutdown Firefox similar to a SIGTERM, right? If that is the case maybe we could use 15
as exit code?
I'm happy to provide a patch once we agreed on a value, and update Marionette to better handle content crash shutdowns.
Comment 6•4 years ago
|
||
I don't think so. If I'm reading the implementation of Services.startup.quit()
correctly it just stops the main event loop and lets shutdown happen normally.
Assignee | ||
Comment 7•4 years ago
|
||
Nick, do you have more insights into how Firefox gets shutdown in this scenario? Is it like a SIGKILL (9) then?
Comment 8•4 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #7)
Nick, do you have more insights into how Firefox gets shutdown in this scenario? Is it like a SIGKILL (9) then?
No, I don't think it's like any signal. If we invoke Services.startup.quit()
, that's a normal/orderly shutdown. (No legacy consumer of that API set a non-zero exit code; it's only the very recent background task work that may set a non-zero exit code.)
I think you just want to fix an "unusual exit code", maybe 3, and then
Services.startup.quit(Ci.nsIAppStartup.eForceQuit, exitCode);
around here. In some way your tests will need to know about the special exit code, but I have no idea if there's an established convention. I guess you could try to use SIGCHLD
, but that seems as confusing as anything else.
Assignee | ||
Comment 9•2 years ago
|
||
I would like to pick this up again, and as such checked a bit more what a good exit code could be. There was nothing that helpful to find, but then I thought about the exit code when Firefox crashes when loading about:crashparent
. And here I can see the usage of 245
.
Nick, would it make sense to re-use the same exit code here? At least it would give the same behavior when loading about:crashcontent
in the browser, which would force a shutdown when the env variable is set. If you agree I could make a patch for it and enhance our Marionette tests.
Comment 10•2 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #9)
I would like to pick this up again, and as such checked a bit more what a good exit code could be. There was nothing that helpful to find, but then I thought about the exit code when Firefox crashes when loading
about:crashparent
. And here I can see the usage of245
.Nick, would it make sense to re-use the same exit code here? At least it would give the same behavior when loading
about:crashcontent
in the browser, which would force a shutdown when the env variable is set. If you agree I could make a patch for it and enhance our Marionette tests.
Sure, 245
is as good as anything else. This is -10
, i.e., -SIGUSR1
, which makes sense for a user-invoked crash.
Assignee | ||
Comment 11•2 years ago
|
||
While working on the patch I found a similar usage of a forced shutdown but for the socket process, which is using 1
instead:
https://searchfox.org/mozilla-central/rev/b72e9d7d63bf499d1d8168291b93d4ec7fde236e/netwerk/ipc/SocketProcessParent.cpp#95-103
I wonder if we should sync both exit codes to 245
or leave that one as 1
to have the possibility to differentiate between forced shutdowns that are triggered by different crashes.
Assignee | ||
Comment 12•2 years ago
|
||
Updated•2 years ago
|
Comment 13•2 years ago
|
||
Comment 14•2 years ago
|
||
bugherder |
Description
•