Bug #10015

Darktable crashes when I import a folder w/ JPG files

Added by Francisco Cribari about 6 years ago. Updated almost 6 years ago.

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


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


Darktable crashes When I tried to import a folder that has Fujifilm X100S JPG (not RAW) files. The backtrace file is available at

I run Ubuntu 14.04.

darktable-crash-14072014.txt (29.2 KB) darktable-crash-14072014.txt Backtrace file - map crash Francisco Cribari, 07/14/2014 09:57 PM


#1 Updated by Francisco Cribari about 6 years ago

Before crashing Darktable gives me the following message:

applied matched GPX location onto 98 image(s)

#2 Updated by Francisco Cribari about 6 years ago

I have just noticed that Darktable crashes when I click in "map" and try to zoom in the existing map. The backtrace file is attached.

#3 Updated by Francisco Cribari about 6 years ago

When I start Darktable as

darktable -d

(no sudo) and try to do the same (zoom in the map) Darktable crashes and see the following information in the terminal

cribari@darwin3:~/Darktable/temp$ darktable -d
[dev_read_history] module `sharpen' version mismatch: history is 1, dt 1.
[dev_read_history] module `monochrome' version mismatch: history is 2, dt 2.
[dev_read_history] module `shadhi' version mismatch: history is 4, dt 4.
[dev_read_history] module `clipping' version mismatch: history is 5, dt 5.
[dev_read_history] module `bilat' version mismatch: history is 1, dt 1.
Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
/home/cribari/Darktable/temp/17238: No such file or directory.
backtrace written to /tmp/darktable_bt_UZMFJX.txt
Segmentation fault (core dumped)

Contents of /tmp/darktable_bt_UZMFJX.txt :

cribari@darwin3:~/Darktable/temp$ sudo cat /tmp/darktable_bt_UZMFJX.txt
this is darktable 1.5+1441~g0901504 reporting a segfault:

/usr/share/darktable/gdb_commands:2: Error in sourced command file:
No stack.

#4 Updated by Francisco Cribari about 6 years ago

This video shows the problem:

#5 Updated by Francisco Cribari about 6 years ago

An update: I copied all image and XMP files to a different folder, deleted the old folder and imported the new folder into Darktable. The good news is that Darktable no longer crashes. The bad news is that I lost all edits made in ten photos. When I open these photos all I see in the history field is 0 - original .

#6 Updated by Ulrich Pegelow almost 6 years ago

  • % Done changed from 0 to 20
  • Priority changed from Low to Medium
  • Status changed from New to Triaged

I think there are two elements in this problem that should be worked on:

  1. darktable may crash if it is confronted with empty xmp data fields - or more generally with any data fields not having the right size. we should catch those cases and deal with them in a more elegant way
  2. for some reason darktable seems to drop the history_params in some xmp files

The first one should be easy to fix. The second one is more problematic as it seems to only occur sparsely.

@Francisco: do you see a chance to narrow down the cases in which empty history_params fields ('<rdf:li/>') occur? Is this linked to a certain period of generation time, a certain kind of input image or a specific module you used? May this be related to #10012?

#7 Updated by Francisco Cribari almost 6 years ago

The Darktable modules that were used in all problematic images are: levels, shadows and highlights, tone curve, watermark. I applied metadata and tags on all images upon importing and after that I geotagged all images using a GPX file. All images (Fujifilm X100S JPG files) were edited on the day they were shot, i.e., May 25. I used whatever git stable version of Darktable (from Pascal's PPA) was available that day. I was able to access that folder/filmroll in Darktable several times in the two weeks that followed. Only recently Darktable started crashing when I tried to import that folder. I was able to reconstruct the edits I made on May 25th in all but one of the problematic images using the exported JPG files and the load sidecar file option. You can find two XMP files (reconstructed and problematic) at

Does that help?

#8 Updated by Ulrich Pegelow almost 6 years ago

From your explanations and from the fact that you have been able to reconstruct the history stacks from exported images, it seems clear that the data corruption happened at some later time - much later than your edits and your exports.

As you have also reported issue #10012: have the images we are talking about here also been re-imported into darktable at some time or have they been in your collection continuously?

I would guess that the data loss here and in #10012 are related. You might have seen in the other ticket that I have at least some theory on what is going on and how one could fix it. I would start working on that after the current regression in master is sorted out. I would then come back to you asking you for some testing.

#9 Updated by Francisco Cribari almost 6 years ago

The folder with these photos was reimported into Darktable a couple of times after the edits and exports. I imported the folder again because it no longer showed up in the list of recently used collections. I did not, however, copy or move the files to a different folder. They remained in the same folder in the same external HD.

#10 Updated by Ulrich Pegelow almost 6 years ago

Re-importing a folder/images that are already in the database has no effect.

Did you remove the images and then later re-import them?

#11 Updated by Francisco Cribari almost 6 years ago

No. I did not add to or remove images from the folder. The folder as reimported into Darktable with the same images it previously had.

#12 Updated by Ulrich Pegelow almost 6 years ago

@Francisco: can you still reproduce this issue, i.e. does darktable currently produce xmp files for you that on re-import cause a crash?

#13 Updated by Francisco Cribari almost 6 years ago

I am afraid not. After our email exchange I deleted the problematic XMP files and reconstructed them using the load sidecar file option together with previously exported JPGs.

Also available in: Atom PDF

Go to top