You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Except when running inside GDB, activating the 'quit' action does close the window, but never terminates the darktable process (for example, I just verified that if I come back an hour later, it will still be present in ps aux | grep darktable output, with a normal, 'S' status).
If I killall darktable, or Ctrl+C in the terminal it was launched from, darktable will usually terminate -- but with a SIGSEGV (backtrace in the log -- looks like it's during an attempt to close the running threads)
The most obvious consequence of this 'never terminating' is: darktable will complain about the database being locked if you try to start it again.
A second, less obvious consequence is that changes to preferences never get saved (hopefully, the fact that this is so helps indicate something about at exactly what point in its exit process DarkTable is hanging). To contrast, changes to lighttable entries or darkroom settings do appear to always be saved correctly, and changes to keyboard shortcuts are also saved correctly.
Running it inside gdb (gdb darktable -> run), there are three scenarios:
it sometimes behaves normally (ie. exits in a reasonable time frame and no longer exists as a process, without any kind of crash.).
At other times, there is a loop of 'New thread .. Thread exited' messages from gdb, with no end.
Alternatively, GDB may simply report a number of threads exiting, but never return; Hitting ^c and entering 'bt' gives something similar to the log: dt_cleanup() -> dt_control_shutdown() -> ??? -> ??? .
So, gdb is the closest I've come to any kind of workaround.
Steps to reproduce
Startup Darktable
(any number of normal darktable things you might do, including the 'absolutely nothing at all' case)
Quit (^Q by default IIRC)
Expected behavior
Exiting normally after a reasonable amount of time (ideally < 30 seconds, but certainly < 5 minutes)
Describe the bug
Except when running inside GDB, activating the 'quit' action does close the window, but never terminates the darktable process (for example, I just verified that if I come back an hour later, it will still be present in
ps aux | grep darktable
output, with a normal, 'S' status).If I
killall darktable
, or Ctrl+C in the terminal it was launched from, darktable will usually terminate -- but with a SIGSEGV (backtrace in the log -- looks like it's during an attempt to close the running threads)The most obvious consequence of this 'never terminating' is: darktable will complain about the database being locked if you try to start it again.
A second, less obvious consequence is that changes to preferences never get saved (hopefully, the fact that this is so helps indicate something about at exactly what point in its exit process DarkTable is hanging). To contrast, changes to lighttable entries or darkroom settings do appear to always be saved correctly, and changes to keyboard shortcuts are also saved correctly.
Running it inside gdb (
gdb darktable
->run
), there are three scenarios:So, gdb is the closest I've come to any kind of workaround.
Steps to reproduce
Expected behavior
Exiting normally after a reasonable amount of time (ideally < 30 seconds, but certainly < 5 minutes)
Logfile | Screenshot | Screencast
dt.log
Commit
No response
Where did you obtain darktable from?
distro packaging
darktable version
5.0.0 ('2:5.0.0-1' in package manager)
What OS are you using?
Linux
What is the version of your OS?
Arch Linux x86_64
Describe your system?
No response
Are you using OpenCL GPU in darktable?
I dont know
If yes, what is the GPU card and driver?
No response
Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip
No response
The text was updated successfully, but these errors were encountered: