Open tbilles opened 10 months ago
TurboGit
commented
10 months ago Looks like it is looked in a Gtk+ call:
#10 0x00007ffff798cd05 in dt_control_expose (voidptr=voidptr@entry=0x0) at /home/tbilles/sources/darktable/src/control/control.c:399
is
gdk_window_get_device_position(gtk_widget_get_window(widget),
gdk_seat_get_pointer(gdk_display_get_default_seat(gtk_widget_get_display(widget))),
&pointerx, &pointery, NULL);
Can you try this #15578? TIA. Just a guess as I cannot reproduce...
tbilles
commented
10 months ago Thanks for the patch! I tried it and unfortunately it still freezes at the same stack.
TurboGit
commented
10 months ago Thanks for the patch! I tried it and unfortunately it still freezes at the same stack.
I had no big hope... So looks like a Gtk+ issue to me, not sure we can do something in dt to fix that.
tbilles
commented
10 months ago My only hope is that it wasn't always like this. Either darktable changed or my system did. I wanted to do a bisect but the database version changed and older versions wouldn't run. It just occured to me that maybe a clean install would also reproduce this and I might be able to use a different database, and yes, we have --cachedir, --configdir, --library and such. I will experiment with those and try to bisect it.
TurboGit
commented
10 months ago @tbilles : Thanks, your effort are much appreciated.
github-actions[bot]
commented
8 months ago This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.
guigri
commented
4 months ago I have the exact same reproducible problem. DT freezes with every export. But: DT does not freeze if I minimize the DT window during the export. Maybe this information will help with troubleshooting. (Sorry if this is redundant / not new information - at least I can't deduce this from the above speculation about a possible GTK problem, for example).
github-actions[bot]
commented
1 month ago This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.
Describe the bug
My workflow ends with selecting all images from an event (usually 10-30 images), and exporting it to jpeg. When I start exporting I switch away from darktable window and do other stuff while the export is working. After a while, all images are successfully exported, I can see them in the filesystem, but when I switch back to the darktable window, it doesn't redraw itself, the screen content stays whatever was there before. And of course it is not responding to user inputs, I have to kill the process and restart it.
It doesn't happen all the time, but frequently enough to be annoying, about a third or half of my exports die like this. I ran darktable from gdb, and captured a stack trace of the frozen state, attached below. I've been having this issue for weeks now, with multiple versions (I regularly build fresh master from source), and with compeletly different sets of images to export, the stack trace all seemed very similar.
Steps to reproduce
I'm not sure it switching to another window is important or not, I didn't experiment with it.
Expected behavior
darktable should come back and respond to user interaction
Logfile | Screenshot | Screencast
Commit
No response
Where did you install darktable from?
self compiled
darktable version
4.5.0+1075~gf66196c741
What OS are you using?
Linux
What is the version of your OS?
Linux Mint 21.1
Describe your system?
I'm using X11 and libgtk version is 3.24.33-1ubuntu2. Let me know if you need more details.
Are you using OpenCL GPU in darktable?
No
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