Segmentation fault in lighttable view

[ilveroluca]

Describe the bug

In lighttable view, darktable loads the last collection the last correction I successfully worked on. I then choose a different, old collection (2013) and darktable segfaults as it loads the image previews.

Steps to reproduce

1. Open darktable
2. Change film roll
3. Wait while thumbnails load

Expected behavior

darktable should load previews without segfaulting

Logfile | Screenshot | Screencast

darktable-no-opencl.stdout.log
darktable-no-opencl.stderr.log

Commit

No response

Where did you obtain darktable from?

OBS

darktable version

4.8.1

What OS are you using?

Linux

What is the version of your OS?

Ubuntu 24.04 LTS

Describe your system?

Kubuntu 24.04 desktop, 16 GB RAM.

17:54 [luca@box ~] inxi -G
Graphics:
  Device-1: NVIDIA TU116 [GeForce GTX 1660 SUPER] driver: nvidia v: 550.90.07
  Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X:
    loaded: modesetting,nouveau,nvidia unloaded: fbdev,vesa
    gpu: nvidia,nvidia-nvswitch resolution: 1: 2560x1440~60Hz 2: N/A

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

NVIDIA GeForce GTX 1660 SUPER, 6 GB, Nvidia Driver Version: 550.90.07

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

Tested with --disable-opencl: did not affect result.

I have found a specific image that triggers the issue. I can share the XMP and ORF (privately) if that can help debug the issue.

I have previously experienced a similar problem, which I reported in #17139; the fix to that problem should be in the version of darktable I'm using though.

[jenshannoschwalm]

Please mail me for investigation

hanno@schwalm-bremen.de

[ilveroluca]

@jenshannoschwalm was unable to reproduce the problem on the current master. Maybe the problem has already been solved post 4.8.1.

I'm sharing the sidecar file here in case someone wants to take a look.

PC243238.ORF.xmp.txt

[ilveroluca]

I have dug a little deeper. I'm finding that many of my images from that period are causing a crash.

Here's another example (raw + sidecar).

• P7162692.ORF.xmp.txt
• https://drive.google.com/file/d/1hD7N1w0smgwJ8ffEY-jRh1On1jY8WD1d/view?usp=sharing

[ilveroluca]

Digging some more...

I found a third picture that doesn't create any problems. I found the only operation that appears in the history of the two pictures causing the crash, but does not appear in the other one is clipping.

These are the 3 sidecar files -- two causing a crash and one not causing a crash:

1. crash-one.xmp.txt
2. crash-two.xmp.txt
3. no-crash.xmp.txt

I scanned through the XML with basic text processing tools. These are the operations only appearing in the crashing histories:

$ comm -2 -3 <(grep operation crash-one.xmp.txt | sort)  <(grep operation no-crash.xmp.txt | sort)
      darktable:operation="clipping"
$ comm -2 -3 <(grep operation crash-two.xmp.txt | sort)  <(grep operation no-crash.xmp.txt | sort)
      darktable:operation="bilateral"
      darktable:operation="clipping"

[jenshannoschwalm]

Thanks for this hint! Clip module is deprecated and we probably missed to make sure the new stuff fits for that module.