my bad, thanks
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X server shutdown
Status in Mozilla Firefox:
Confirmed
Status in
(In reply to Henrik Skupin [:whimboo][⌚️UTC+1] from comment #81)
> (In reply to Sylvestre Ledru [:Sylvestre] from comment #80)
> > SIGTERM is now handled thanks to bug 1837907
>
> Bug 1837907 was only about Linux. Reading through the comments I can see that
> we may already support this on
SIGTERM is now handled thanks to bug 1837907
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X server shutdown
Status in Mozilla
(In reply to Sylvestre Ledru [:Sylvestre] from comment #80)
> SIGTERM is now handled thanks to bug 1837907
Bug 1837907 was only about Linux. Reading through the comments I can see
that we may already support this on Windows, but does that also include
MacOS?
--
You received this bug
The last needinfo from me was triggered in error by recent activity on
the bug. I'm clearing the needinfo since this is a very old bug and I
don't know if it's still relevant.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in
(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #77)
> The severity field for this bug is relatively low, S3. However, the bug has 7
> duplicates, 34 votes and 66 CCs.
> :mossop, could you consider increasing the bug severity?
>
> For more information, please visit
The severity field for this bug is relatively low, S3. However, the bug has 7
duplicates, 34 votes and 66 CCs.
:mossop, could you consider increasing the bug severity?
For more information, please visit [auto_nag
** Changed in: firefox
Importance: Medium => Unknown
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X server shutdown
Status in
Is it not on contradiction with the idea of free software to force users
to quit exclusively using the UX interface and forbid them to close
thanks to CLI?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
By the way, yes, I shut down well by clicking on the system shutdown
function, I do not do this by a long press on the power button.
I did not get that behavior under Ubuntu, only since I migrated to
Debian 10 but I experience it on 2 computers under Debian 10.
Trye, "quitting Firefox properly"
Once upon a time Firefox had -remote for executing commands on linux like that,
but it was removed back in Firefox 39. This also allowed doing useful stuff
like telling firefox to reload a url.
but also:
-remote "xfeDoCommand(close)"
Regrettably there's no replacement for this super useful
I'm quiet surprised to discover that the bug I'm facing is 14 years old...
Hopefully it will be solved some day.
On Gnome, would a gnome extension creating a "close Firefox and shutdown
button" work ? What would be the command? quit Firefox && sleep 5 && shutdown -
h now? I don't know how to
So no easy way to solve this issue for most users... Hopefully some day...
Thank you for answering @nemo.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox
*** Bug 1634905 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X server shutdown
*** Bug 1629049 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X server shutdown
Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-
8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these
notifications (and sorry!)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
** Changed in: firefox
Status: In Progress => Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X server shutdown
Status
I'd like this feature, however if this is difficult to implement then a
workaround for my use case would be if the firefox command could support
a '--close' or similar option to exit gracefully, even if handled
asynchronously and I had to poll to wait for exit.
--
You received this bug
Comment on attachment 8959924
Bug 336193 - P1: Use SignalPipeWatcher to detect signals SIGTERM/SIGINT/SIGHUP
and quit application gracefully.
https://reviewboard.mozilla.org/r/228682/#review235956
r+ with or without the SIG_IGN case.
--
You received this bug notification because you are a
Comment on attachment 8959924
Bug 336193 - P1: Use SignalPipeWatcher to detect signals SIGTERM/SIGINT/SIGHUP
and quit application gracefully.
https://reviewboard.mozilla.org/r/228682/#review235302
> I based this off nsProfileLock's CATCH_SIGNAL() which does not
register for signal handlers that
*** Bug 365749 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X server shutdown
Status
*** Bug 1032010 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X server shutdown
Comment on attachment 8959924
Bug 336193 - P1: Use SignalPipeWatcher to detect signals SIGTERM/SIGINT/SIGHUP
and quit application gracefully.
https://reviewboard.mozilla.org/r/228682/#review235302
(I'm not an XPCOM peer and so I considered passing the nsDumpUtils part to
Nathan, but the initial
(In reply to James Graham [:jgraham] from comment #45)
> Marionette has a method to invoke shutdown,
> but sending the response races with closing the marionette connection, so it
> isn't reliable. Signalling the process with SIGTERM would be the obvious
> solution, except for this bug. So we
Created attachment 8963553
Bug 336193 - P2: Use a second SIGTERM in killPid() to ensure parent process is
killed.
killPid() needs to do more than send a single SIGTERM to the parent
process now that it only triggers graceful shutdown, sending a second
SIGTERM terminates it forcefully like
Created attachment 8959924
Bug 336193 - P1: Use SignalPipeWatcher to detect signals SIGTERM/SIGINT/SIGHUP
and quit application gracefully.
Review commit: https://reviewboard.mozilla.org/r/228682/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/228682/
--
You received
(sorry, by which I meant to say more specifically: 'killall firefox' has
the same issue, it prompts a session crash dialog for me on next
startup. It's just not something I use often since I usually use the
close button which works, but on shutdown the same mechanism is used -
of course with a
Any news on this?
killall firefox does not work at all (Ubuntu).
pkill -x firefox-bingives a crash dialog when starting firefox next time.
A simple and gentle way to end firefox from Linux commandline would be nice.
--
You received this bug notification because you are a member of
Comment on attachment 8959924
Bug 336193 - P1: Use SignalPipeWatcher to detect signals SIGTERM/SIGINT/SIGHUP
and quit application gracefully.
Review request updated; see interdiff:
https://reviewboard.mozilla.org/r/228682/diff/1-2/
--
You received this bug notification because you are a member
Comment on attachment 8959924
Bug 336193 - P1: Use SignalPipeWatcher to detect signals SIGTERM/SIGINT/SIGHUP
and quit application gracefully.
https://reviewboard.mozilla.org/r/228682/#review235302
> Is the |dispatchQuit| single quit logic necessary?
> It looks like nsAppStartup::mShuttingDown
Comment on attachment 8963553
Bug 336193 - P2: Use a second SIGTERM in killPid() to ensure parent process is
killed.
https://reviewboard.mozilla.org/r/232486/#review237940
Harnesses built on top of Marionette client as test runner will use
SIGKILL to force killing the browser process. It is
(In reply to Karl Tomlinson (:karlt) from comment #48)
> (In reply to James Graham [:jgraham] from comment #45)
>
> > Marionette has a method to invoke shutdown, but sending the
> > response races with closing the marionette connection, so it
> > isn't reliable. Signalling the process with
(In reply to jonas from comment #63)
That is a bug (IMO) in most distros' shutdown/reboot sequences, where
they give applications no time to shut down before sending SIGKILL. I
would report to your distro.
--
You received this bug notification because you are a member of Desktop
Packages, which
Does this bug also include the session not being properly counted as
regularly closed when I shut down the computer normally with firefox
open? (And firefox offering me a misguided tab restore after a supposed
"crash" on next run) Because that's what I'm seeing here as a normal
Linux desktop user.
Comment on attachment 8963553
Bug 336193 - P2: Use a second SIGTERM in killPid() to ensure parent process is
killed.
https://reviewboard.mozilla.org/r/232486/#review237940
r+ with improved logging.
It seems odd that this is the only place in our test automation
requiring this change. Other
Here's a revised version of the SignalPipeWatcher patch.
* SIGTERM/SIGINT/SIGHUP all do a graceful exit. I tested Chromium, VLC
and GIMP using strace with these signals and they all exit normally
returning exit codes and not signals.
* SignalPipeWatcher does not chain to previous handler and
'killall firefox' has no timeout as far as I know, so I think that is
completely irrelevant
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on
Comment on attachment 8959924
Bug 336193 - P1: Use SignalPipeWatcher to detect signals SIGTERM/SIGINT/SIGHUP
and quit application gracefully.
Review request updated; see interdiff:
https://reviewboard.mozilla.org/r/228682/diff/2-3/
--
You received this bug notification because you are a member
Someone needs to rebase the patch here and push it to try. I'd be
willing to mentor this, but I don't have the time to do it myself.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Comment on attachment 8750107
Bug 336193 handle SIGTERM in SignalPipeWatcher then in the main thread to quit
I think this approach will work well, thanks.
SIGTERM will have no effect if Firefox gets stuck during shutdown, but I guess
that's reasonable because SIGTERM is intended to effect normal
Still a major problem, 9 years after raising this I only can see
discussions about? Firefox is not able to handle a standard SIGTERM? For
me a reason to change. Sorry to be this rude, but it is really a shame.
--
You received this bug notification because you are a member of Desktop
Packages,
Comment on attachment 8750107
Bug 336193 handle SIGTERM in SignalPipeWatcher then in the main thread to quit
Let's at least review all the patches here.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
Comment on attachment 8626516
bug336193.patch
Unfortunately, the last paragraph of comment 23 is still relevant.
(In reply to Kestrel from comment #39)
> * nsAppStartup::Quit calls nsIAppShell::Exit asynchronously which does most
> of the work so it doesn't block the signal handler.
It is more
Created attachment 8626516
bug336193.patch
Summary:
* nsProfileLock is already rigged for handling signals and is already
terminating (fatally) so it is only a small change to make it clean, this is
preferable to a GTK-specific implementation.
* A clean quit should be performed for SIGINT
Created attachment 8750107
Bug 336193 handle SIGTERM in SignalPipeWatcher then in the main thread to quit
What about the attempt in this patch? I intercept SIGTERM using
"SignalPipeWatcher" as suggested, then I pass a task to the main thread
so it calls
(In reply to Christian Holler (:decoder) from comment #33)
>
> Are there any remaining problems with the attached patch?
What happened back in December 2012? Did the patch make it to the
official source?
The issue is still present in the current version of Firefox for Linux.
--
You received
The SignalPipeWatcher class defined in xpcom/base/nsDumpUtils.cpp might
be of interest — it's used to trigger memory reports from a signal
handler (via the usual pipe-to-self trick), which sounds like the same
basic problem as this bug.
--
You received this bug notification because you are a
Comment on attachment 8626516
bug336193.patch
Review of attachment 8626516:
-
Karl, mind reviewing this? I'm not qualified to review unix signal
handling code.
--
You received this bug notification because you are a member of
This is a problem for geckodriver and for anything else that's using
marionette to control the browser (e.g. various test harnesses including
wpt). If we don't shut down the browser gracefully we lose out on the
ability to do various things that depend on clean shutdown (certainly
leak logging,
** Changed in: firefox
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X server shutdown
Status
*** Bug 1088008 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X server shutdown
Still not resolved? FWIW, I would deal with SIGINT and SIGTERM using
the same handler. Functionally this should be no different than
whatever happens when the user chooses File/Quit or hits Ctrl-Q.
--
You received this bug notification because you are a member of Desktop
Packages, which is
I have the same problem, essentially with JS Test Driver trying to close
Firefox (I assume using SIGTERM). Sometimes when JS Test Driver tries to
restart the browser, the This is embarrassing dialog pops up and JS Test
Driver is unable to capture the browser to run unit tests. I see this
problem
Getting this fixed should fix some issues with coverage measurement and
external applications using the browser. My current problem is that an
external testing application uses SIGTERM to signal the browser to
terminate but GCOV data is not written out because no regular exit is
performed.
Are
(In reply to Nathan Froyd (:froydnj) from comment #31)
I assume you mean re-raising once we've handled application shutdown?
Yes.
Oof, that's quite some complexity.
Yes, it could well be too much trouble. It can be attacked separately
if/when that turns out to be important for anything.
(In reply to Karl Tomlinson (:karlt, offline til July 2) from comment #29)
Is there a reason you chose to use SA_RESTART? Not sure it makes much
difference in practice, but I would have expected an interrupt signal to try
to abort ASAP rather than restarting a system call.
I would expect that
Think also about what happens when a signal is received after the
nsAppShell is deleted.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant
Comment on attachment 618671
patch
Communicating via pipe is the only reasonable async-signal-safe way that I
know to signal the event loop.
eForceQuit on SIGINT sounds sensible to me.
I wouldn't implement this for SIGQUIT for the reasons you list in comment 26.
It should be possible to share
Created attachment 618671
patch
Redirecting f? to karlt as bsmedberg suggests. Updated patch with
SIGQUIT handling as well.
I left SIGINT doing a eForceQuit; from comments in this bug, it sounds
like people start firefox from the command line and then C-c it. For
those sorts of usecases, it
I am not the right person to review this, having never written anything
useful with signal handlers. If I understand this correctly, the signal
handler itself is signaling a pipe which wakes up the event loop. Is
this because it is not safe to make any GTK calls from within the signal
handler? I
(In reply to Benjamin Smedberg [:bsmedberg] from comment #15)
ok, fix it! I'd happily review a patch!
(In reply to Benjamin Smedberg [:bsmedberg] from comment #25)
I am not the right person to review this, having never written anything
useful with signal handlers.
I am confused. :)
If I
Oh, I confused SIGINT with SIGQUIT. SIGINT should presumably do normal
prompting, I guess SIGQUIT doesn't need to as you said.
Somebody who knows signal handlers and GTK well should be the primary
code reviewer for this patch (which isn't me). I suggest karlt.
--
You received this bug
Created attachment 608074
patch
Here's a better, somewhat more verbose patch that doesn't require
anything beyond what we already use. When receiving SIG{INT,TERM} and
restarting, we now display about:home with an option to restore your
last session instead of the this is embarrassing page.
As
Breakpad doesn't handle SIGTERM, so you should be okay there. You will
probably need to make sure that your code interacts properly with the
profile locking code, since the purpose of that signal handler is to
clean up the profile lock correctly upon exit.
--
You received this bug notification
(In reply to Ted Mielczarek [:ted] from comment #19)
Breakpad doesn't handle SIGTERM, so you should be okay there. You will
probably need to make sure that your code interacts properly with the
profile locking code, since the purpose of that signal handler is to clean
up the profile lock
I suppose the right thing to do here then is either:
a) Drop SIGTERM support from nsProfileLock, make your new code call into the
nsProfileLock code to unlock the profile before exiting.
or
b) Forget about your new code, just tweak nsProfileLock to special-case SIGTERM
and do the handling you're
Two things:
1. You should probably use nsAppStartup::Quit because it will do the Right
Things. This includes sending the proper shutdown notifications to code that
needs to clean up.
2. Should probably make this generic enough to work on all unixish systems
instead of just GTK2. Sounds like
(In reply to Michael Wu [:mwu] from comment #22)
1. You should probably use nsAppStartup::Quit because it will do the Right
Things. This includes sending the proper shutdown notifications to code that
needs to clean up.
Mmm, good point.
2. Should probably make this generic enough to work on
Created attachment 609331
patch
New patch using nsIAppStartup; also fewer printfs.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X
Created attachment 607268
patch
Here's a patch which appears to DTRT on Linux. I don't have a Mac
machine and I even less familiar with the OS X event loop than I am with
the Linux one, so that bit would have to come from someone else.
--
You received this bug notification because you are a
Comment on attachment 607268
patch
Actually, this does the right thing, but it would drastically inflate
the version of GTK we require; g_unix_signal_add is said in the docs to
be available from 2.30 onwards (though this version isn't actually
available from the website...?), and we require 2.14.
ok, fix it! I'd happily review a patch!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X server shutdown
Status in The Mozilla Firefox
Six years later... Firefox 10 has the same bug Firefox 2 had. It is
ridiculous that Firefox shows the This is embarrassing message when it
receives a normal SIGTERM. People are hacking around the problem by
disabling session restore completely:
This bug still occurs as it has for years.
This bug doesn't deserve to finish in the bug's graveyard, forgotten and denied
by every one.
The Won't Fix status is not encouraging.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox
74 matches
Mail list logo
