-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deadbeef crash detector triggers on Linux after shutting down / signing out from X session #2927
Comments
…ted by quitting a linux desktop session (#2927)
I added a workaround.. not really a proper solution for the problem, but it will prevent deadbeef's crash detector from triggering after computer reboots etc. |
Hello Oleksiy, thanks for working on this but i just tried the latest static dev build and the problem does not appear to be fixed for me ? Neither when killing deadbeef from the command line nor when exiting my (plasma) session... |
Killing deadbeef from command line is basically the same thing as forcing deadbeef to crash (also known as "force-close"). It is expected to detect this as a crash, and suppress the resume functionality. I haven't tested with plasma though, only with GNOME, I don't know whether GTK can handle plasma session shutdown, but I'll try it out. |
Yes, I can confirm that the workaround that I added is not compatible with KDE. Sorry. |
Meanwhile i have tested under XFCE (4.18) where your fix is working ! I suppose it makes sense that a GTK3-specific API (or convention) might not work under qt/kde ... TBH i am very happy with db 1.8.8 but in the long run it'd be annoying to be stuck with an older revision. Thanks again. |
I have added a SIGTERM handler, which is supposed to perform a quicksave and reset the crash marker. |
actually I tested it with KDE, and unfortunately it didn't work at all. |
Unfortunately the new fix doesn't work with either KDE or GNOME.. so I'll have to remove it, since it doesn't make any sense. |
I'm "downgrading" this issue to "Enhancement", since this issue is not really a bug, but more a lack of X11 session management integration (if such thing exists at all, which I'm not sure about). |
Fine with me. On XFCE, deadbeef 1.9.5 definitely shows the crash notification when restarted after a session termination stopped the program. So your fix seems to improve things at least under GTK3-based environments. |
a workaround that I use and works on every desktop I have tried is to delete the (lock file) aka (running) prior to loading eg. i add this to $HOME/.fluxbox/startup in fluxbox I add this to the startup script |
hey, thanks for the tip ! I added this as a KDE autostart script |
no problem program: bash as for "defeats the crash detection i suppose" -- I disagree. since deadbeef still gives a crash report if it crashes during the session.. so the only way it doesn't work is if the whole system crashes. in which case it's not deadbeefs problem anyway |
in my opinion it's an uncleaned lock file ... putting it in /tmp would likely solve the problem for all boots .. assuming /tmp is cleaned at boot, as for log out and back in deadbeef could call ps -e | grep X and if X time is below a value then no crash report... that would also work for a reboot so the /tmp option would no longer be necessary anyway glad it works |
It is not an uncleaned lock file. The problem is that with X session management vs GTK applications it's a really difficult thing to achieve, since killing X server would trigger a handler in GTK which terminates the application process without giving it any chance to clean up. The proper fix is to receive a proper termination signal from the desktop environment / X session manager. |
"without giving it any chance to clean up". lol :) |
The process gets terminated by calling exit in a GTK SIGTERM handler when it detects that X server is down. edit: sorry, I remembered that what I wrote is not entirely correct.
|
At the very least it should follow convention and handle SIGTERM, whether or not it gets enough time to clean up isn't in your control. It should call the same thing that sending --quit does now. |
@putmeinatoaster would you mind if I ask you to provide a link to the convention you're referring to? Never heard of one, so I would not know where to look. |
Oh sorry, in english when we say "convention" it does not mean hard and fast rule. It means more like a commonly agreed upon way to handle things. Like a crash detection system shouldn't leave files behind when the user asks polity for the program to exit cleanly (SIGTERM). |
Did you even read the other comments in this issue? It's not like I haven't tried to do what you suggest. It doesn't work. And it doesn't work specifically in the case of GTK applications on Linux. If you think you know better, and it's supposed to work -- feel free to implement it, test it, and submit a patch. |
This is a diff on main.c |
I'm sure about this too. This would not work at all. |
not at all? I mean im using it now and can send SIGTERM and then restart the player with the 'save_resume_state' having finished and cleared its 'running' file. So far the only bit that seemed odd was that i had to redo my playlists... |
You haven't tried ending X session and then looking what happens, did you? |
No that will never work. If X crashes then nothing to be done there. Handling SIGTERM specifically is all I wanted. |
I'm not talking about crashing X. I'm talking about quitting X session cleanly. |
(which is what this specific bug is about) |
Oh. Then that depends on your setup. For example KDE sends SIGTERM and waits a bit before closing. I do pretty much the same with a shutdown script. No idea about gnome of xfce. |
Yes, they wait enough. But remember that X is just another process, which gets SIGTERM signal just the same. I don't know what usecase you're trying to solve, but your patch would not solve this bug. |
Also, your patch will make this bug much more of a problem, since there will be a lot of undefined behavior when deadbeef process is killed while it's running SIGTERM handler. This was the original behavior of deadbeef, which had to be removed because it caused way more problems, than not doing anything at all. |
If you're having a hard time finding the information I'm referring to -- please read this comment. |
Just mine i guess :P |
I posted about this on the deadbeef sourceforge pages here.
Deadbeef version: 1.9.5 (also 1.9.4, 1.9.2)
OS: linux MX21 compatible with debian 11 "bullseye")
Every now and then (typically on DE session startup, KDE plasma in my case), deadbeef reports a crash occurred e.g (for v1.9.5 below)
The problem can be reproduced by killing deadbeef from the command line. The next started instance then shows the above message. I have seen this with 1.95 (static+deb), 1.94(static), 1.92(static).
The same problem however, does not occur with deadbeef v1.8.8.
As per our preliminary discussion in the linked thread, this may be caused by some startup loop detection introduced in 1.9.x.
Perhaps one way to remediate this would be to differentiate terminations initiated by a DE from hard crashes (or SIGKILL).
The text was updated successfully, but these errors were encountered: