Hi all, not sure if this is the right place/tag for this but I’ve been having an issue with DT and can’t say whether it’s a bug or something wrong on my end. I was editing a raw file earlier today and had an unexpected crash while using the retouch module. Crashes are pretty rare for me but not unheard of, especially with multiple wavelet scales going, so I didn’t think much of it. However, when I reopened DT and tried to resume editing the same photo, I started getting unhandled exceptions in the light room and was unable to reopen or view that specific raw file (at some points, the thumbnail view would load, but I had no luck getting the full size render open).
Next I tried copying the raw file and XMP to a different directory, and had the same issue. Eventually I tried copying over the history from the original to the one in the new directory with only the last step in the history removed. The retouch step I was on for the initial crash hadn’t saved in the XMP, so the step that I removed was an instance of color calibration in channel mixer mode. I wasn’t sure how stable things would be, but I finished the edit with no issues, exported, and closed out of DT. A bit later, I re-opened it, and ran into the same issue as before - unhandled exceptions that caused a crash. Since then, I haven’t been able to reopen it with DT at all, even in separate directories on a different drive. I was able to successfully apply the same XMP to a different (random) image + close and reopen darktable, but it’s weird to me that the root cause could be tied to the specific image I was working on. I’d appreciate any help or pointers in the right direction; I can post the original/finished XMP and any log/backtraces if it’s helpful but I’m reluctant to post the raw file for privacy reasons (regarding the subject of the photo)
Please post the crash logs, some specifics about your OS, the version of DT.
If you can load your problem xmp file using a different raw file and it still crashes, please post the xmp file.
Sure, I’m on Windows 10- the system info says Version 10.0.19044 (Build 19044). DT version is 4.0.1.
This is the XMP file in question, so far it’s worked with several other non-duplicate files:
P1001454_01.RW2.xmp (111.8 KB)
There are quite a few crash logs by now - Each time I reproduced the issue, I would get 4-6 separate unhandled exception popups, each with a new backtrace. Here’s a few from the most recent try (omitted duplicates):
darktable_bt_5WSUT1.txt (26.9 KB)
darktable_bt_PZ4VT1.txt (49 Bytes)
Plus the one from the initial crash:
darktable_bt_83D7T1.txt (29.1 KB)
By the way, thanks for your time looking into this
1 Like
Quick update: I haven’t been able to reproduce the issue from scratch, but I did have a similar issue on another image from the same shoot. On this one, I was able to get all my edits done, but when I tried to export I started getting more unhandled exceptions, and now can’t open that directory in the lighttable/darktable views if the thumbnail is visible onscreen. I suspect it has something to do with the module order I’m using. In this case and the one from yesterday, I had moved the retouch module up in the pipeline, just before filmic RGB. I think the retouch instances came after color calibration instances both times, but each one had many other steps first so no reason to suspect a CC/retouch interaction just yet.
Here’s the xmp from today’s crash:
P1001487_02.RW2.xmp (291.3 KB)
Plus some more log files:
darktable_bt_17XTT1.txt (26.3 KB)
darktable_bt_XC8VT1.txt (49 Bytes)
And in case anyone knows, should I not be moving instances of the retouch module around? No idea if it’s the root cause, it’s just been a common theme right before both of these crash scenarios
One more update, sorry for not including this earlier but I wanted to test a bit and make sure. Disabling all masked instances of color calibration and color balance rgb in the edit history let me re-open the image in other directories in DT. This isn’t a fix or anything - I need those. I was disabling them by selectively copying and pasting the history from the image in the original directory to a test folder. I’ll see if I can reproduce the crash by manually adding back those operations. So far, including a copy of any masked instance of the two modules from the original edit history has caused another crash, but I haven’t tested on other images, or with new masked instances on the partially recovered edits