Darktable crashing in Windows

[resolution13]

Is there an existing issue for this?

• I checked and did not find my issue in the already reported ones

Describe the bug

Hi. I downloaded the latest version, which is 5.0.1 and I get a message when I open it from the get-go, saying that the OpenCL compiler settings have been reset. When I try to edit an image that I have edited in the past, Darktable just crashes. I never had this problem in the previous version, which is 4.1, and I really need a step-by-step instruction to correct this error. Thank you.

Steps to reproduce

1. Start "Darktable"
2. A message states "Your OpenCL compiler settings for all devices have been reset to default."
3. Click onto an image edited in the past to make adjustments.
4. The software crashes without any warning signs.

Expected behavior

No response

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

darktable.org / GitHub release

darktable version

5.0.1

What OS are you using?

Windows

What is the version of your OS?

Windows 11, version 24H2

Describe your system

No response

Are you using OpenCL GPU in darktable?

None

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]

We'll need you to generate and post a crash log. See https://www.darktable.org/about/faq/#faq-windows-bugs for instructions. Attach (don't paste) the resulting file after the crash in a followup.

You can also help us narrow down the issue by disabling OpenCL in the preferences - start darktable, and go directly into Preferences||Processing and uncheck "activate OpenCL suppport". Hit Escape to exit and save the preferences, then close darktable, restart it, and try to edit an image.

Do you get a crash on an image which wasn't previously edited, i.e. freshly imported with 5.0.1?

[resolution13]

Hi. Here is the log generated when Darktable crashed:

darktable-log.txt

I removed the photo from Darktable and re-imported it. That seemed to have fixed the issue. The photo in problem was edited in an earlier version (4.2) and carried over to the current version. As of now, there is no problem and the pop-up for the OpenCL compiler hasn't popped up today.

Could the editing in the previous version may have caused an issue? (Potentially an answer to your last question) Even though there's no problem at the moment, I would like to know any alternative solutions should the same problem arises and that removing a problematic photo doesn't resolve the issue.

[pehar1]

This log does not help, you did not start darktable with a debug option. See FAQ mentioned by @ralfbrown .

[ralfbrown]

Crashing on an old sidecar file is a bug which should be fixed. We'll need you to share a sidecar which causes the crash so that we can look at what settings in it might have experienced a regression since it was saved (we had a case where filmicrgb settings saved in late 2020 were incorrectly processed a couple of years later).

[resolution13]

Where can I locate a sidecar file? Really appreciate your help.

[pehar1]

Besides the image file. See https://darktable-org.github.io/dtdocs/en/overview/sidecar-files/sidecar/

[resolution13]

I removed the photo of issue from Darktable and re-improted it back, which seem to have fixed the issue. Would you still be able to see previous issues in a sidecar file?

[ralfbrown]

No, if the image now works, the sidecar file has also been updated. We need a sidecar from an image which actually crashes darktable at the time you copy it.

[github-actions]

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.

[victoryforce]

No, if the image now works, the sidecar file has also been updated. We need a sidecar from an image which actually crashes darktable at the time you copy it.

@resolution13 without this we can't move forward and fix the bug, so if you are no longer able to provide such a file, I suggest closing the issue as one that has no chance of being resolved.