Version: 4.6 (using KDE 4.6.2) OS: Linux Hello, Firefox is crashing while logging out as KDE is logging out too quickly. I have found this problem in a Gentoo bug report and now reporting it here. The original reporter is Navid Zamani (http://bugs.gentoo.org/show_bug.cgi?id=364109) Reproducible: Always Steps to Reproduce: Firefox: 1. Install All-In-One Sidebar, re-start Firefox 2. Open the sidebar (e.g. the addons list) 3. Re-start Firefox. The sidebar should still be open. 4. Now close the sidebar again. 5. Log out of KDE, and log back in. Result: Firefox restarts, and the sidebar still is open. Expected: If you manually re-start Firefox instead of logging out in point 5, Firefox will re-start with the sidebar closed. Firefox data loss example: 1. Install Tab Mix Plus. 2. In the settings, enable Tab Mix Plus session management instead of the built-in one. This is, because other than the built-in, the TMP one notifies users of crashes. Instead of quietly restoring the tabs. 3. Open some tabs with pages in them. 4. Log out of KDE and back in. Result: TMP session management notifies you of a crash and asks if it should restore the session. Expected: If you had instead closed Firefox normally, it would not have notified you of a crash, and no data would have been lost. It can also be reproduced with any setting that is retained in memory without immediate writing to disk. With a bit of playing around and hunting, especially with add-ons, many of those can be found. Beware that even without any of those, Firefox still crashes and still can have data loss. Unfortunately I don’t know how to enable a kind of logging that survives a crash. In Thunderbird the behavior is the same. The best example of KDE causing data loss can be shown with Java apps. 1. Install Sancho. 2a. In the transfers window change the column order, size, or sorting. 2b. Or: Change anything in Tools → Preferences → sancho: * 3. Log out of KDE and log back in. Result: If the app even restarts at all, the column and preferences changes will be lost. Expected: Just like when manually closing the app and re-starting it, the settings and changes should be kept. Actual Results: See above. Expected Results: See above. I hope it is ok, that the severity is major. I know that there is a simple workaround: close these programs before shutting down. But as Firefox not shows that there was a problem (with eventually data loss) many users do not know about the risk.
Are you implying that Firefox doesn't implement X session management correctly and we should work around it in KDE?
(In reply to comment #1) > Are you implying that Firefox doesn't implement X session management correctly > and we should work around it in KDE? I do not know the internal mechanism of session management. Therefore I cannot say where the problem is. If it is a more general problem I can post a bugreport to Firefox. For me it seems as KDE should "simple" wait a little bit longer to let Firefox shut down properly and then close X.
> I do not know the internal mechanism of session management Try http://www.google.com/search?q=x+session+management > For me it seems as KDE should "simple" wait a little bit longer The KDE session manager (ksmserver) waits for the reply from all applications that register for X session management. If Firefox indicates that all data has been committed, or if Firefox crashes and therefore closes the connection to the session manager, then ksmserver has no reason to wait any longer and will inform the login manager that the session can be terminated. I would suggest to ask Firefox developers if the problem could be in specific plugins. As for Java applications, I doubt that they support session management at all. I haven't seen API in Java that maps to XSM. I am reassigning this report to ksmserver for further inspection.
Actually, (In reply to comment #3) > The KDE session manager (ksmserver) waits for the reply from all applications > that register for X session management. Actually, it kills everything after a timeout of 10 seconds. (Last time I looked at the code.) Which, in case of some big apps being open and memory swapping going on, is not enough. But of course, that doesn’t mean that it’s killed that way in my case. Also, Firefox is considered a "legacy session management" program. Why, when it’s apparently doing proper X session management, I do not know. > I would suggest to ask Firefox developers if the problem could be in specific > plugins. I did tests with all plugins disabled. One problem is, that vanilla Firefox is very good at acting as if nothing happened when it crashed. It restores its tabs. And most things you do, get saved to disk right away anyway. But it still crashes. Which can be seen by the few things that Firefox saves only at exit. (Including late changes to the periodically saved data.) So making a small extension which saves its data only at exit, may be the best way to reproduce this. > As for Java applications, I doubt that they support session management at all. > I haven't seen API in Java that maps to XSM. Well, they don’t have to. As long as they are terminated properly. See, when I change a column width in a table in a Java program that saved those widths at exit (like Sancho or, I think, ThinkingRock), then when I use the [x] button in the window decoration, or the KDE program close shortcut (like Alt-F4 in Windows), and re-start it, the column width is kept. When I leave the program running, exit the session, log in again, and re-start the program manually (yep, there’s no auto-start-again support), the column width is lost. The problem seems to be, that ksmserver doesn’t seem to use the normal program close command, but something more forcefully. It may well be, that a normal SIGTERM already is that more forceful way. In that case, just changing that, would already solve the problem. Oh, and obviously, the timeout should be configurable, as e.g. in my case, I do not *ever* want to lose data, just because ksmserver was too impatient and I happen to have more programs than usually open. :) (I’d set it to 2 minutes here. Better safe than sorry.) > I am reassigning this report to ksmserver for further inspection. Thank you. If you need any info, I’m happy to help. :)
So apparently nobody at KDE cares? At all? You just murder every child that hasn’t left the class room after 10 seconds? :/ Does that mean the only solution is to patch ksmserver to a different timeout myself…? :( But seriously… 10 seconds and no warning, no “Would you like to wait a little longer or kill them off?”? What are you thinking? Even Windows does that. And it doesn’t have any real session management at all.
subscribe
Ok, I’ve found a very reliably and easily reproducible example of how the session management fails for all cases where there are a couple of large applications open. The steps can be found over at Gentoo’s bug tracker: https://bugs.gentoo.org/show_bug.cgi?id=364109#c8 And the results of me doing it: https://bugs.gentoo.org/show_bug.cgi?id=364109#c9 A temporary workaround, doing what KDE should be doing in the first place, manually: https://bugs.gentoo.org/show_bug.cgi?id=364109#c10 Now all you guys have to do, is implement the workaround as real code inside your own session management, and you’re good. It’s all done for you. How about that?
*** This bug has been confirmed by popular vote. ***
ping
By the way: This is still the case. With all software based on the Mozilla platform or on Java. Easily reproducible by simply e.g. opening any Mozilla-based program after an update, seeing its “new version” tab, closing it, logging out of KDE, logging in again, watching the program come back up with the tab still there as if it was never closed. When doing the same but closing/opening the program manually instead of logging out/in, it works as expected and the tab stays closed. Same thing with changing table column width in (I think any Java program, but I know it for a fact in) e.g. Sancho. I still use my complete workaround of the KDE session management, because frankly, it is just… FAIL. I wonder though: Does not a single of the KDE developers use Firefox or Thunderbird? I thought it was more popular. Because if anyone would use it, it would be fixed in an hour. :(
Added a patch to make the timeout configurable here: https://git.reviewboard.kde.org/r/106090/
(In reply to comment #12) Awesome, Martin! But I wonder: Would it be possible for ksmserver to ask the user if he thinks the applications are hanging and would like to kill them, or if he wants to continue to wait for another $timeout seconds? Because that would allow one to have a short timeout and still not have everything killed outright. And I think this functionality existed in the past…
Git commit e648950adef6bca37c554f586b611006e041d931 by Martin Koller. Committed on 22/08/2012 at 16:49. Pushed by mkoller into branch 'KDE/4.9'. make the client shutdown timeout configurable sometimes the timeout for applications to shutdown is too short, e.g. when running on old hardware, having lots of applications open, browsers with many tabs, etc. This patch adds two config entries with which you can define the timeout before ksmserver kills the apps. In the [General] section of ksmserverrc you can define: legacySaveTimeoutSecs (default = 4 seconds) clientShutdownTimeoutSecs (default = 15 seconds; was 10 before) Related: bug 248459 FIXED-IN: 4.9.1 REVIEW: 106090 M +13 -5 ksmserver/legacy.cpp M +7 -1 ksmserver/shutdown.cpp http://commits.kde.org/kde-workspace/e648950adef6bca37c554f586b611006e041d931
Git commit 7213d2081e0bc8fb4a34f0af9f526da9380b9e95 by Martin Koller. Committed on 22/08/2012 at 16:49. Pushed by mkoller into branch 'master'. make the client shutdown timeout configurable sometimes the timeout for applications to shutdown is too short, e.g. when running on old hardware, having lots of applications open, browsers with many tabs, etc. This patch adds two config entries with which you can define the timeout before ksmserver kills the apps. In the [General] section of ksmserverrc you can define: legacySaveTimeoutSecs (default = 4 seconds) clientShutdownTimeoutSecs (default = 15 seconds; was 10 before) Related: bug 248459 FIXED-IN: 4.9.1 REVIEW: 106090 M +13 -5 ksmserver/legacy.cpp M +7 -1 ksmserver/shutdown.cpp http://commits.kde.org/kde-workspace/7213d2081e0bc8fb4a34f0af9f526da9380b9e95
I can imagine that sometimes it would make sense to ask the user what to do if the app does not react after a timeout. If you think this wish shall be implemented, please open a new issue. thanks.
(In reply to comment #16) > I can imagine that sometimes it would make sense to ask the user what to do > if the app does not react after a timeout. > If you think this wish shall be implemented, please open a new issue. > thanks. Martin, this was the whole point and reason I filed the bug #248459 in the first place. Not to have a configurable timeout time, but to have that dialog. I quote: > and at the end, when there are still open apps, show a dialog, asking if they should be (something equivalent to) SIGQUIT, -TERM, or -KILLed, or if shutdown should be cancelled. So while I appreciate there being a configurable timeout, this doesn’t solve the problem that if something surpasses the timeout… whatever it may be set to… you don’t get to decide at all, and it just outright kills it for you. The problem with that, is that it, as it seems to happen more and more often, is treating the user like a complete idiot who doesn’t know what he’s doing, and is nothing more than meat with eyes. ;) In other words: The MS Clippy syndrome of the software knowing better what you want, than yourself, /without even asking you/. It’s incredibly annoying and if you’d be treated like that in every day situations, you’d feel insulted. It’s a computer. Not an iPad. We have brains. Ask the user. :) So while this bug here is fixed, bug #248459 still is unresolved.
This has always annoyed me too. And to be honest, I don't think the code change made to address this bug is a fix. It is a (very welcome!) workaround. You can't expect people to dive into the guts of KDE and add an obscure option to a hidden away configuration file to fix a problem that is so common and impacts so many people (everybody who uses Firefox and/or Thunderbird).
(In reply to comment #18) > (everybody who uses Firefox and/or Thunderbird). Don’t forget *all* Java applications. (As far as I know.)