darktable is suddenly crashing without warning

Hi all, apologies for the delay in coming back to this thread. Been away for the weekend.

Blockquote
@kofa
Do you use a Debian-based distro? If so, dpkg -l can list all installed packages, dpkg -l darktable could specifically show darktable, and dpkg -S /usr/bin/darktable would show the package owning the file.

Yes, I am on mxlinux which is based on debian.

$ dpkg -l darktable
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================================
ii  darktable      4.2.1-4      amd64        virtual lighttable and darkroom for photographers

Blockquote
@garibaldi
…Then run /opt/darktable/bin/darktable -d pipe -d opencl and see what happens[/quote]

$ /opt/darktable/2024-07-09/bin/darktable -d pipe -d opencl
darktable 4.9.0+62~gb6d54d8e38
Copyright (C) 2012-2024 Johannes Hanika and other contributors.

Compile options:
  Bit depth              -> 64 bit
  Debug                  -> DISABLED
  SSE2 optimizations     -> ENABLED
  OpenMP                 -> ENABLED
  OpenCL                 -> ENABLED
  Lua                    -> DISABLED
  Colord                 -> DISABLED
  gPhoto2                -> DISABLED
  GMIC                   -> DISABLED - Compressed LUTs are NOT supported
  GraphicsMagick         -> DISABLED
  ImageMagick            -> DISABLED
  libavif                -> DISABLED
  libheif                -> DISABLED
  libjxl                 -> DISABLED
  OpenJPEG               -> DISABLED
  OpenEXR                -> DISABLED
  WebP                   -> ENABLED

See https://www.darktable.org/resources/ for detailed documentation.
See https://github.com/darktable-org/darktable/issues/new/choose to report bugs.

    13.0926 [dt_get_sysresource_level] switched to 1 as `default'
    13.0926   total mem:       32040MB
    13.0926   mipmap cache:    4005MB
    13.0926   available mem:   16020MB
    13.0926   singlebuff:      250MB
    13.0943 [opencl_init] opencl disabled via darktable preferences
    13.0945 [dt_dlopencl_init] could not find default opencl runtime library 'libOpenCL'
    13.0946 [dt_dlopencl_init] could not find default opencl runtime library 'libOpenCL.so'
    13.0948 [opencl_init] opencl library 'libOpenCL.so.1' found on your system and loaded, preference 'default path'
    13.3640 [opencl_init] found 1 platform
[opencl_init] found 1 device

[dt_opencl_device_init]
   DEVICE:                   0: 'NVIDIA GeForce RTX 3070'
   CONF KEY:                 cldevice_v5_nvidiacudanvidiageforcertx3070
   PLATFORM, VENDOR & ID:    NVIDIA CUDA, NVIDIA Corporation, ID=4318
   CANONICAL NAME:           nvidiacudanvidiageforcertx3070
   DRIVER VERSION:           535.183.01
   DEVICE VERSION:           OpenCL 3.0 CUDA, SM_20 SUPPORT
   DEVICE_TYPE:              GPU, dedicated mem
   GLOBAL MEM SIZE:          7971 MB
   MAX MEM ALLOC:            1993 MB
   MAX IMAGE SIZE:           32768 x 32768
   MAX WORK GROUP SIZE:      1024
   MAX WORK ITEM DIMENSIONS: 3
   MAX WORK ITEM SIZES:      [ 1024 1024 64 ]
   ASYNC PIXELPIPE:          NO
   PINNED MEMORY TRANSFER:   NO
   AVOID ATOMICS:            NO
   MICRO NAP:                250
   ROUNDUP WIDTH & HEIGHT    16x16
   CHECK EVENT HANDLES:      128
   TILING ADVANTAGE:         0.000
   DEFAULT DEVICE:           NO
   KERNEL BUILD DIRECTORY:   /opt/darktable/2024-07-09/share/darktable/kernels
   KERNEL DIRECTORY:         /home/bruce/.cache/darktable/cached_v3_kernels_for_NVIDIACUDANVIDIAGeForceRTX3070_53518301
   CL COMPILER OPTION:       -cl-fast-relaxed-math
   CL COMPILER COMMAND:      -w -cl-fast-relaxed-math  -DNVIDIA_SM_20=1 -DNVIDIA=1 -I"/opt/darktable/2024-07-09/share/darktable/kernels"
   KERNEL LOADING TIME:       0.3048 sec
[opencl_init] OpenCL successfully initialized. internal numbers and names of available devices:
[opencl_init]		0	'NVIDIA CUDA NVIDIA GeForce RTX 3070'
    13.7550 [opencl_init] FINALLY: opencl PREFERENCE=OFF is AVAILABLE and NOT ENABLED.
[dt_opencl_update_priorities] these are your device priorities:
[dt_opencl_update_priorities] 		image	preview	export	thumbs	preview2
[dt_opencl_update_priorities]		0	-1	0	0	-1
[dt_opencl_update_priorities] show if opencl use is mandatory for a given pixelpipe:
[dt_opencl_update_priorities] 		image	preview	export	thumbs	preview2
[dt_opencl_update_priorities]		0	0	0	0	0
[opencl_synchronization_timeout] synchronization timeout set to 200
[dt_opencl_update_priorities] these are your device priorities:
[dt_opencl_update_priorities] 		image	preview	export	thumbs	preview2
[dt_opencl_update_priorities]		0	-1	0	0	-1
[dt_opencl_update_priorities] show if opencl use is mandatory for a given pixelpipe:
[dt_opencl_update_priorities] 		image	preview	export	thumbs	preview2
[dt_opencl_update_priorities]		0	0	0	0	0
[opencl_synchronization_timeout] synchronization timeout set to 200
    14.8099 [dt_action_locate] action 'tethering' doesn't exist
    14.8100 [dt_shortcuts_load] action path 'views/tethering/hide histogram' not found
    14.8100 [dt_action_locate] action 'live_view' doesn't exist
    14.8100 [dt_shortcuts_load] action path 'lib/live_view/toggle live view' not found
    14.8100 [dt_action_locate] action 'live_view' doesn't exist
    14.8100 [dt_shortcuts_load] action path 'lib/live_view/zoom live view' not found
an error occurred while trying to execute gdb. please check if gdb is installed on your system.
backtrace written to /tmp/darktable_bt_2UMYQ2.txt
Segmentation fault

I can see at the end it says check to see if gdb is installed. Why would it NOT be, if darktable was running fine a few days ago?

This file does not exist within the /tmp folder on my system, either.
I think it was @pinkadoe who cited the same issue?

I just did:

 sudo apt install gdb

and then ran darktable with:

/opt/darktable/2024-07-09/bin/darktable -d pipe

The app launched, but then quit after 10-15 seconds.

So, you have both 4.2 and the current development version installed. You may want to get rid of the old version.

No idea about the crash, though.

I have in the meantime recorded a bug at Red hat bugzilla. Fedora’s maintainer has given instructions how to get a proper backtrace Bugzilla. I als needed to enable saving coredumps (/etc/systems/logind.conf). I have posted my back trace (which doesn’t help me further).

Planning now to check whether I can fix this by rolling back updates since the last time DT worked…

Were there any other backtrace files generated in /tmp after it quit (now that gdb is installed)?

Didn’t look like it (though must admit I didn’t examine it closely)

Addition: darktable-cli runs normally, no issues.

There are files and folders in the /tmp folder, but nothing that mentions darktable.

$ ls
MozillaUpdateLock-6AFDA46A1A8AD48
snap-private-tmp
ssh-XXXXXXBpZcBA
systemd-private-6e8940b9069e4906a67321f21e396c6a-chrony.service-rj5nDu
systemd-private-6e8940b9069e4906a67321f21e396c6a-colord.service-HFcDnU
systemd-private-6e8940b9069e4906a67321f21e396c6a-haveged.service-d43JIs
systemd-private-6e8940b9069e4906a67321f21e396c6a-ModemManager.service-4SshWK
systemd-private-6e8940b9069e4906a67321f21e396c6a-systemd-logind.service-VU2jU8
systemd-private-6e8940b9069e4906a67321f21e396c6a-upower.service-2dxEsE
Temp-eae5e01d-0dd2-475a-9b4d-ed858e6db89d

I have now removed version 4.2 (which came with the distro when I installed it).
I also tried booting with the previous kernel, as I think someone suggested earlier in this thread that the new kernel (released last week) MIGHT have been the culprit, but alas, no, even with the previous kernel, darktable is still crashing out after 15 seconds.
Next steps? :frowning:

Clean config? Rename ~/.config/darktable, delete (or rename) ~/.cache/darktable.

Hmm. THAT has allowed darktable to run without crashing.
I guess now, I have to individually try bringing the original data.db and library.db files back in to the active directory to see which one causes the crash, right?

I think you should try both at the same time, to figure out if the problem is triggered by darktablerc or by the others.

Well, it seems that moving the old data.db file into the active directory did NOT cause the crash to reappear.
Which suggests that if I now try and bring in the old library.db file, it probably WILL.
Wish me luck…

1 Like

My hunch is also library.db, one or more images with the stack causing a processing problem.

Well, colour me surprised!
Putting the original library.db file back into service has also NOT caused dt to crash.
So @kofa, perhaps as you’ve suggested it was darktablerc causing the havoc?
Should I throw THAT original file back into the mix to confirm?

Yep. And then, if it does trigger there crash, you can used divide and conquer to find the problematic line(s).

Yep, darktablerc caused the crash.
@kofa, exactly how does one “divide and conquer”? :slight_smile:

Wow. That could be a very time consuming process, right?
I mean, my darktablerc file must have 1000 lines in it…
What exactly is in darktablerc? What do I lose if I can’t narrow down to the offending line of code, and just go with the newly-created version?