Bug #11282

Freeze on corrupt RAW or XMP

Added by Filip Bunkens over 3 years ago. Updated over 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
git master branch
hardware architecture:


Last night while I was working on a raw file, the corresponding XMP file got corrupted. This resulted in darktable constantly using 1 thread of my cpu at 100%.

After restart of DT or reboot of the computer, this behavior still persisted.

I took a long time (5-10 minutes) to show the thumbnails in my library, this normally takes about 30sec - 1min
Whenever I selected the offending photo, darktable would freeze and use 98 % cpu power during 45 min after which it would still be frozen, but no longer use any cpu.

DT would not detect that the XMP is corrupt and try time and time again to open the file.

Once I figured out what was happening, I moved the offending file out of DT and out of the folder, copied the raw from a backup and all was fine.

As DT was not throwing any errors and the whole of DT was very slow and unresponsive it was very troublesome to troubleshoot and I took me several hours to figure this out.

Attached are the RAW and XMP that caused the problem.

I have tried this on the 2.0.7 release and the release.2.1.0.r2127.g3c9b03d-1 from git master, they both behave exactly the same.

How to reproduce:

- Import attached Raw file with xmp next to it.
- Try to open the file or scroll in the lighttable

NOTE: when the bug is resolved please remove the raw file from this bugreport, the photo contains people and there is no model release for publication.


#1 Updated by Tobias Ellinghaus over 3 years ago

  • System changed from other GNU/Linux to all
  • Affected Version changed from 2.0.7 to git master branch
  • % Done changed from 0 to 20
  • Target version set to 2.2.0
  • Status changed from New to Triaged
  • Category set to Masks

Seems to be masks related.

#2 Updated by Ulrich Pegelow over 3 years ago

The cause is a path (Path #5 in shadows&highlights) with a HUGE feathering area/radius, about 170 times larger than the image dimensions. Even if only a small portion of that area lies in the image frame, processing needs to consider all 10^7 border points which takes eternities. If I am patient enough the image buffers (preview, center view) get finally processed.

However, the main point is how to prevent mask shapes with insane values. Currently almost no sanity check is done when in comes to adjustments of shape size and feathering area by mouse scroll. darktable even crashes if a path shape gets enlarged aggressively.

This needs to be fixed with some sensible upper limits.

#3 Updated by Ulrich Pegelow over 3 years ago

As written earlier the major fix will need to prevent mask shapes with insane values being generated.

This won't help in the case of this image. Therefore I added a repaired sidecar file. I have removed the offending mask (Path #5) which had been used in one of the shadows&highlights instances. It was obviously meant to mask the right side of the face of the central person in the image and needs to be redone. In order to use the repaired xmp file please follow these steps:

1) open darktable in lighttable mode and remove the image from the database (panel selected image(s)).
2) download the repaired xmp file and let it replace the existing one
3) re-import the image or folder

#4 Updated by Ulrich Pegelow over 3 years ago

  • % Done changed from 20 to 100
  • Status changed from Triaged to Fixed

commit 81ba4b3e8a584db7e01b6bdb73e16407cd98a1fb should prevent this issue in future.

Also available in: Atom PDF

Go to top