Skip to content
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

Darktable window closes, but process never terminates (unless running darktable inside gdb) #18240

Open
0ion9 opened this issue Jan 19, 2025 · 2 comments

Comments

@0ion9
Copy link

0ion9 commented Jan 19, 2025

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:

  1. it sometimes behaves normally (ie. exits in a reasonable time frame and no longer exists as a process, without any kind of crash.).
  2. At other times, there is a loop of 'New thread .. Thread exited' messages from gdb, with no end.
  3. 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

  1. Startup Darktable
  2. (any number of normal darktable things you might do, including the 'absolutely nothing at all' case)
  3. Quit (^Q by default IIRC)

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

@ralfbrown
Copy link
Collaborator

Likely duplicate of #18208. May be addressed by #18061.

@jenshannoschwalm
Copy link
Collaborator

Plus 8edeb69

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@0ion9 @ralfbrown @jenshannoschwalm and others