search

DeaDBeeF-Player / deadbeef

DeaDBeeF Player
https://deadbeef.sourceforge.io/
Other
1.61k stars 176 forks source link

Deadbeef crash detector triggers on Linux after shutting down / signing out from X session #2927

Open PGcritter opened 1 year ago

PGcritter commented 1 year ago

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)

We had a crash. Will not resume the saved session to avoid a crash cycle.
starting deadbeef 1.9.5 [static]
server_start
searching for GUI plugins in /home/baldyeti/.local/lib64/deadbeef
searching for GUI plugins in /home/baldyeti/.local/lib/deadbeef
searching for GUI plugins in /opt/deadbeef/lib/deadbeef
load_plugin_dir /opt/deadbeef/lib/deadbeef: scandir found 57 files
found gui plugin ddb_gui_GTK2.so
added GTK2 gui plugin
found gui plugin ddb_gui_GTK3.so
added GTK3 gui plugin
load gui plugin
checking GUI plugin: GTK2
checking GUI plugin: GTK3
found selected GUI plugin: GTK3
loading plugin /opt/deadbeef/lib/deadbeef/ddb_gui_GTK3.so
loading plugins from /home/baldyeti/.local/lib64/deadbeef
loading plugins from /home/baldyeti/.local/lib/deadbeef
loading plugins from /opt/deadbeef/lib/deadbeef
load_plugin_dir /opt/deadbeef/lib/deadbeef: scandir found 57 files
loading plugin /opt/deadbeef/lib/deadbeef/aac.so
loading plugin /opt/deadbeef/lib/deadbeef/adplug.so
loading plugin /opt/deadbeef/lib/deadbeef/alac.so
loading plugin /opt/deadbeef/lib/deadbeef/alsa.so
loading plugin /opt/deadbeef/lib/deadbeef/artwork.so
loading plugin /opt/deadbeef/lib/deadbeef/cdda.so
loading plugin /opt/deadbeef/lib/deadbeef/converter.so
loading plugin /opt/deadbeef/lib/deadbeef/converter_gtk2.so
loading plugin /opt/deadbeef/lib/deadbeef/converter_gtk3.so
loading plugin /opt/deadbeef/lib/deadbeef/dca.so
loading plugin /opt/deadbeef/lib/deadbeef/ddb_dsp_libretro.so
loading plugin /opt/deadbeef/lib/deadbeef/ddb_dumb.so
loading plugin /opt/deadbeef/lib/deadbeef/ddb_mono2stereo.so
loading plugin /opt/deadbeef/lib/deadbeef/ddb_out_pw.so
dlopen error: /opt/deadbeef/lib/deadbeef/ddb_out_pw.so: undefined symbol: PW_LOG_TOPIC_DEFAULT
trying /opt/deadbeef/lib/deadbeef/ddb_out_pw.fallback.so...
plugin ddb_out_pw.so not found or failed to load
loading plugin /opt/deadbeef/lib/deadbeef/ddb_shn.so
loading plugin /opt/deadbeef/lib/deadbeef/ddb_soundtouch.so
loading plugin /opt/deadbeef/lib/deadbeef/dsp_libsrc.so
loading plugin /opt/deadbeef/lib/deadbeef/ffap.so
loading plugin /opt/deadbeef/lib/deadbeef/ffmpeg.so
loading plugin /opt/deadbeef/lib/deadbeef/flac.so
loading plugin /opt/deadbeef/lib/deadbeef/gme.so
loading plugin /opt/deadbeef/lib/deadbeef/hotkeys.so
loading plugin /opt/deadbeef/lib/deadbeef/in_sc68.so
loading plugin /opt/deadbeef/lib/deadbeef/lastfm.so
loading plugin /opt/deadbeef/lib/deadbeef/m3u.so
loading plugin /opt/deadbeef/lib/deadbeef/mms.so
loading plugin /opt/deadbeef/lib/deadbeef/mp3.so
loading plugin /opt/deadbeef/lib/deadbeef/musepack.so
loading plugin /opt/deadbeef/lib/deadbeef/notify.so
loading plugin /opt/deadbeef/lib/deadbeef/nullout.so
loading plugin /opt/deadbeef/lib/deadbeef/opus.so
loading plugin /opt/deadbeef/lib/deadbeef/oss.so
loading plugin /opt/deadbeef/lib/deadbeef/pltbrowser_gtk2.so
loading plugin /opt/deadbeef/lib/deadbeef/pltbrowser_gtk3.so
loading plugin /opt/deadbeef/lib/deadbeef/psf.so
loading plugin /opt/deadbeef/lib/deadbeef/pulse.so
loading plugin /opt/deadbeef/lib/deadbeef/rg_scanner.so
loading plugin /opt/deadbeef/lib/deadbeef/shellexec.so
loading plugin /opt/deadbeef/lib/deadbeef/shellexecui_gtk2.so
loading plugin /opt/deadbeef/lib/deadbeef/shellexecui_gtk3.so
loading plugin /opt/deadbeef/lib/deadbeef/sid.so
loading plugin /opt/deadbeef/lib/deadbeef/sndfile.so
loading plugin /opt/deadbeef/lib/deadbeef/supereq.so
loading plugin /opt/deadbeef/lib/deadbeef/tta.so
loading plugin /opt/deadbeef/lib/deadbeef/vfs_curl.so
loading plugin /opt/deadbeef/lib/deadbeef/vfs_zip.so
loading plugin /opt/deadbeef/lib/deadbeef/vorbis.so
loading plugin /opt/deadbeef/lib/deadbeef/vtx.so
loading plugin /opt/deadbeef/lib/deadbeef/wavpack.so
loading plugin /opt/deadbeef/lib/deadbeef/wildmidi.so
loading plugin /opt/deadbeef/lib/deadbeef/wma.so
starting plugin GTK3 user interface
starting plugin AAC player
starting plugin Adplug player
starting plugin ALAC player
starting plugin ALSA output plugin
starting plugin Album Artwork
starting plugin Audio CD player
starting plugin Converter
starting plugin Converter UI
starting plugin Converter UI
starting plugin dts decoder
starting plugin Resampler (Libretro)
starting plugin DUMB module player
starting plugin Mono to stereo
starting plugin Shorten player
starting plugin Soundtouch
starting plugin Resampler (Secret Rabbit Code)
starting plugin Monkey's Audio (APE) decoder
starting plugin FLAC decoder
starting plugin Game-Music-Emu player
starting plugin Hotkey manager
starting plugin SC68 player (Atari ST SNDH YM2149)
starting plugin last.fm scrobbler
starting plugin M3U and PLS support
starting plugin mms vfs
starting plugin MP3 player
starting plugin MusePack decoder
starting plugin OSD Notify
starting plugin Null output plugin
starting plugin Opus player
starting plugin OSS output plugin
starting plugin Playlist Browser
starting plugin Playlist Browser
starting plugin PSF player using Audio Overload SDK
starting plugin PulseAudio output plugin
starting plugin ReplayGain Scanner
starting plugin Shell commands
starting plugin Shellexec UI
starting plugin Shellexec UI
starting plugin SID player
starting plugin WAV/PCM player
starting plugin SuperEQ
starting plugin tta decoder
starting plugin cURL vfs
starting plugin ZIP vfs
starting plugin Ogg Vorbis decoder
starting plugin VTX player
starting plugin WavPack decoder
starting plugin WildMidi player
starting plugin WMA player
starting plugin stdio vfs
starting plugin FFMPEG audio player
selected output plugin: PulseAudio output plugin

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).

Oleksiy-Yakovenko commented 1 year ago

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. Also, it works only with GTK3.

PGcritter commented 1 year ago

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...

Oleksiy-Yakovenko commented 1 year ago

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.

Oleksiy-Yakovenko commented 1 year ago

Yes, I can confirm that the workaround that I added is not compatible with KDE. Sorry. I don't know how to make this work, but I'll keep the issue open.

PGcritter commented 1 year ago

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.

Oleksiy-Yakovenko commented 1 year ago

I have added a SIGTERM handler, which is supposed to perform a quicksave and reset the crash marker. It's not guaranteed to work in all situations, since X11 vs GTK communication during shutdown is not great, but I think it might work in some situations.

Oleksiy-Yakovenko commented 1 year ago

actually I tested it with KDE, and unfortunately it didn't work at all. Seems like the application gets killed before it has a chance to perform any cleanup.

Oleksiy-Yakovenko commented 1 year ago

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.

Oleksiy-Yakovenko commented 1 year ago

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).

PGcritter commented 1 year ago

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.

macneisj commented 1 year ago

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 rm ~/.config/deadbeef/running && deadbeef &

PGcritter commented 1 year ago

hey, thanks for the tip ! I added this as a KDE autostart script (took me a while as the documentation is outdated; as of plasma 5.20 it belongs in ~/.config/plasma-workspace/env/) and it seems to work fine (i tried a couple logoff/logon iterations with no problem) sort of defeats the crash detection i suppose but i am on 1.9.5 now, thanks again !

macneisj commented 1 year ago

no problem on the kde neon 5.27.7 i have just created a bash script and put it in the autostart

program: bash arguments: /path/script.sh

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

macneisj commented 1 year ago

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

Oleksiy-Yakovenko commented 1 year ago

It is not an uncleaned lock file. It's specifically made to detect the crashes / unclean terminations. It cleans only if the application is terminated cleanly.

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. However I'm yet to find a working example code that would work. Nothing I tried worked so far.

macneisj commented 1 year ago

"without giving it any chance to clean up". lol :) anyway it sounds like it does recieve a SIGHUP? or something of sort

Oleksiy-Yakovenko commented 1 year ago

The process gets terminated by calling exit in a GTK SIGTERM handler when it detects that X server is down. This occurs regardless of whether the app installs its own SIGTERM handler, the process would be killed before this handler is executed.

edit: sorry, I remembered that what I wrote is not entirely correct. This is the correct sequence of events:

  1. X session sends SIGTERM to all processes
  2. SIGTERM code is running in deadbeef
  3. GTK received a signal from the X server that it's dying / dead
  4. GTK calls exit
  5. whatever code was running within SIGTERM is aborted (no way to guarantee completion) -- no way to save files etc. To the application it basically looks like a crash.
putmeinatoaster commented 7 months ago

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.

Oleksiy-Yakovenko commented 7 months ago

@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.

putmeinatoaster commented 7 months ago

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).

Oleksiy-Yakovenko commented 7 months ago

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.

putmeinatoaster commented 7 months ago

This is a diff on main.c sig.txt I have literally never edited a c file before nor do I know how to make pull requests... or how to format github comments. :P It's practically copy pasta from the first google hit when you search "sigterm c example" I will run this for a while but I don't get around with desktop environments to test. I really don't think i know better. I'm sure it breaks something.

Oleksiy-Yakovenko commented 7 months ago

I'm sure it breaks something.

I'm sure about this too. This would not work at all.

putmeinatoaster commented 7 months ago

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...

Oleksiy-Yakovenko commented 7 months ago

You haven't tried ending X session and then looking what happens, did you?

putmeinatoaster commented 7 months ago

No that will never work. If X crashes then nothing to be done there. Handling SIGTERM specifically is all I wanted.

Oleksiy-Yakovenko commented 7 months ago

I'm not talking about crashing X. I'm talking about quitting X session cleanly.

Oleksiy-Yakovenko commented 7 months ago

(which is what this specific bug is about)

putmeinatoaster commented 7 months ago

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.

Oleksiy-Yakovenko commented 7 months ago

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. If it finishes terminating before other processes (such as deadbeef) get a SIGTERM -- GTK will terminate the process, and SIGTERM will not be handled. This is pretty much the whole story about this bug and why it's open.

I don't know what usecase you're trying to solve, but your patch would not solve this bug.

Oleksiy-Yakovenko commented 7 months ago

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.

Oleksiy-Yakovenko commented 7 months ago

If you're having a hard time finding the information I'm referring to -- please read this comment. It covers it in detail.

putmeinatoaster commented 7 months ago

Just mine i guess :P I would never put deadbeef in that position. I love her too much!