Crash in idle darkroom

[kofa73]

Describe the bug

I had an image opened, but was not editing it, I was just comparing the contents with that of another window. I was dragging the other window over the screen when darktable crashed.

Steps to reproduce

I had a raw image open in the darkroom. Later I found the crash is reproducible even if a simple JPG is open in the darkroom.

I was dragging an image viewer window, partially covering darktable. The darkroom in darktable was zoomed to 100%, but I later found that was not a requirement. Screen resolution is 4K. The crash is reproducible within seconds on my machine. The window I was dragging over darktable was a Java app, but I can reproduce the problem with e.g. dragging KDE's text editor, kate, over darktable.

Expected behavior

dt should not crash

Logfile | Screenshot | Screencast

dt-crash.txt

Commit

No response

Where did you obtain darktable from?

self compiled

darktable version

4.9.0+1048~g0739a92dea

What OS are you using?

Linux

What is the version of your OS?

Ubuntu 24.04

Describe your system?

NVidia 1060/6GB Ryzen 5 5600X, 64 GB

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

NVidia 1060/6GB 550.120-0ubuntu0.24.04.1

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[pehar1]

Can't reproduce on my system (three HD monitors side by side, desktop 5760 x 1080 px), darktable takes one monitor (1920x1080).

Tried with LXImage-Qt (image viewer), PCManFM-Qt (filemanager), FeatherPad (texteditor), LibreOffice, Firefox, Database Manager (self written Java application), Eclipse (IDE)

darktable 4.9.0+1065-g633fea155a
OS : Linux 6.8.0-48-generic / Ubuntu 24.04.1 LTS
Memory : MemTotal: 65759336 kB Graphics Card : Product Name : NVIDIA GeForce RTX 2060 Graphics Card : Driver Version : 550.120 OpenCL installed : Device OpenCL C Version OpenCL C 1.2 OpenCL activated : yes Xorg : Version: 1:7.7+23ubuntu3 Desktop : LXQt GTK+ : 3.24.41 Glib : ldd (Ubuntu GLIBC 2.39-0ubuntu8.3) 2.39 gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0 CMAKE_BUILD_TYPE : release

[kofa73]

Here: reproducible with/without OpenCL, and even if darktable's window is quite small, dragging xterm over it.

[pehar1]

Tried again with multiple windows overlaying darktable, moving windows around, bringing them to background / foreground, changing sizes ... no crash.

X session or wayland session ?

Only a wild guess : I remember a strange problem (not a crash) reported here related to the window manager used (#15948). Maybe it would be worth trying a different window manager ? I use openbox.

[kofa73]

I use Xorg with KDE.

[kofa73]

I've tried with openbox, and that crashed, too. NB: openbox behaved very strange on my system, dragging or closing a window never repainted the background, leaving the last drawn window visible. Nevertheless, the crash is the same (the window I dragged this time was whatever terminal openbox gave me).

[parafin]

This looks like video drivers or Xorg problem. Check what relevant packages you’ve updated recently and try to roll them back to an old version.

[kofa73]

This looks like video drivers or Xorg problem. Check what relevant packages you’ve updated recently and try to roll them back to an old version.

The darktable 4.8.1 AppImage does not crash. The locally compiled 4.8.1 does not crash, either. Time to bisect, I guess. I'll report back.

[jenshannoschwalm]

Is it related to the filmstrip being shown?

[kofa73]

Not related to filmstrip, also occurred with it turned off.

Bisect failed, as sometimes I was not patient enough (the crash would sometimes occur in seconds, sometimes only after a longer time, and I probably did not wiggle the mouse long enough). I'm restarting it.

[kofa73]

OK, I was on the wrong track, it has something to do with the stack stored in the DB. Does not occur with a clean DB, which makes bisecting harder, because I normally use a temp DB for bisecting, especially given that some versions cannot even read the latest DB. However, I always import the same images, and they have XMP files next to them.

That's it for today, I'm tired.

[ralfbrown]

Crash while idling in darkroom view says "sidecar autosave" or "background thumbnailer" to me. Does the crash happen with those two features disabled?

[kofa73]

I'll have to test more. But would those (sidecars autosave and background thumbnailer) not cause issues regardless of moving another window over darktable? If I just let darktable idle (without moving another application across its window), the crash does not occur. It is also strange that it does not happen with only the XMP file (imported into a fresh DB), I need my current DB (or the cache, who knows) to crash it. But there is no activity going on (no pipeline runs, no perf or opencl output etc.).

[parafin]

IMHO it's more likely to be about darktablerc settings, which affect how darkroom looks, than database.

[kofa73]

Yes, but I've already tested with a config dir containing my darktablerc. Nevertheless, I'll test again -- sometime.

[jenshannoschwalm]

At least the thumbnailer reports activity via the logs so you get noticed ...

[ralfbrown]

My thought was that the autosave or thumbnailer (especially the latter) are doing something which causes a problem when the GUI thread responds to a window manager event at the same time....

[jenshannoschwalm]

Forgot to mention, backthumbs tests for current view and is just idling while in view is darkroom...

[kofa73]

OK, here is a -d all -d verbose log:

• I started darktable
• Opened an image in the darkroom
• Waited a few seconds for things to settle (I think the last log entry from that is at the 6.8987 mark)
• Started moving a window over the darkroom (from 10.0599)

There are lots of dt_view_paint_surface entries (I assume redrawing the screen), as well as quite a few like 14.7273 expose module [full] demosaic 800 2752x1812, px=3193 py=108 No other processing messages, though. crashlog.zip

[kofa73]

I've moved darktablerc out of the way. Darktable created a new one, then crashed before the GUI would show. Trying to restart darktable results in the same crash. That probably warrants a separate bug report, but I'll add the file here, in case not, please check. crash-with-fresh-darktablerc.zip

Update: Interestingly, after restoring darktablerc, I have no issue opening image 12647, which is the one mentioned in one of the last log entries: 2.9361 [mipmap_cache] generate mip 4 for ID=12647 from jpeg Deleting the mipmap cache did not help. The image is a JPG with a basic stack:

[jenshannoschwalm]

The log might hint to a control job not working correctly.

There is one more way - as mentioned before elsewhere - to make dt crash immediately. Start it from the console and click on the close button as soon as possible and the chance for a crash happening in dt_control_shutdown is very high. @ralfbrown any idea? Until the splash-thing we had everything running up before using darktable.gui - now it's at least partly initialized and we might try to use control on the ui before it's completely safe?

[ralfbrown]

We could indeed need some guards to avoid dereferencing null pointers or the like. It looks like either darktable.control or darktable.mipmap_cache may have been uninitialized.

@kofa73 From your latest backtrace, it looks like darktable was starting up with the lighttable in culling mode. Does the crash happen if you are in some other mode at the time the previous run exits? (it didn't for me with startup in either fixed or dynamic culling modes)

[kofa73]

@ralfbrown

@kofa73 From your latest backtrace, it looks like darktable was starting up with the lighttable in culling mode. Does the crash happen if you are in some other mode at the time the previous run exits?

There was no previous run -- that crash occurred after I moved my dartablerc out of the way. I can later try what happens if I leave it in place, switch to the culling mode (which I never use), and try to start darktable. But then it seems it'll really need a separate bug report.