Bug #8857

Some Nikon D1 NEF files crash Darktable

Added by Lewis Collard about 5 years ago.

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


Affected Version:
hardware architecture:


Certain files from a Nikon D1 digital SLR crash Darktable 1.0.5, at least on Ubuntu 10.04 32-bit and Ubuntu 12.04 64-bit. This does not happen with all of them, only some for reasons I am unable to determine.

Under Ubuntu 10.04 32-bit, the crash happens in both darkroom and lighttable modes, however the file is opened.

Under Ubuntu 12.04 64-bit, saddlark on IRC reports a crash doing the following:

20:42 < saddlark> This is what I do:
20:43 < saddlark> - click Image button on top left
20:43 < saddlark> - select the image
20:43 < saddlark> - the image opens in darkroom, and I am able to zoom etc
20:43 < saddlark> - when I return to lighttable, dt crashes

The files (I am unable to upload them here; I get a "connection interrupted" error): - Crashes Darktable under both Ubuntu 12.04 64-bit and 10.04 32-bit - Crashes Darktable under Ubuntu 12.04 64-bit, but doesn't crash Ubuntu 10.04 32-bit - Backtrace under Ubuntu 10.04 32-bit - saddlark's backtrace under Ubuntu 12.04 64-bit

dtcrash1.txt Magnifier (31.1 KB) Christian Tellefsen, 08/11/2012 08:30 PM

gdb.txt Magnifier (19.4 KB) Simon Spannagel, 08/18/2012 08:17 AM

darktable_bt_AHFIJW.txt Magnifier (24.4 KB) Lewis Collard, 08/23/2012 09:10 PM


#1 Updated by Christian Tellefsen about 5 years ago

Added updated dtcrash1.txt (now with all threads)

#2 Updated by Lewis Collard about 5 years ago

For anyone who missed the discussion on IRC:

It's worth noting that this is, as saddlark noted today, looking like a subtle timing issue/race condition because this does not occur for me all the time. In particular, sometimes simply moving the file to a different directory solves the problem; even if it's a different directory with only one file in it as it was before, this does not happen. Sometimes it'll open in place. Running it on a different, somewhat slower computer (1.6ghz Intel T2330 laptop, also 32-bit Ubuntu 10.04) never produces the crash at all, no matter how many times it is run. I don't think it's specific to D1 NEFs as such; I'd speculate that it doesn't happen with other NEFs simply because they take longer to render than the relatively tiny D1 NEFs and thus perhaps avoid the timing bug that way. Thus, it's worth fixing even if you didn't care about supporting the D1, since the timing bug is bound to resurface somewhere, eventually.

Running a build of git master through gdb, it happens in src/develop/imageop.c:1736. Context:

1731          // add up to one pixel difference.
1732          // we have this check with the hope the branch predictor will get rid of it:
1733          if(in3 + offm >= in &&
1734             in3 + offM < in + bpp*iw*ih)
1735          {
1736            for(int k=0; k<3; k++) out2[k] = // in3[2-k];
1737              CLAMP(((int32_t)in3[bpp*half_pixel*sj      + 2-k] +
1738                     (int32_t)in3[bpp*half_pixel*(si+sj) + 2-k] +
1739                     (int32_t)in3[bpp*half_pixel*si      + 2-k] +
1740                     (int32_t)in3[2-k])/4, 0, 255);

#3 Updated by Simon Spannagel almost 5 years ago

  • Category set to General
  • Status changed from New to Triaged
  • Priority changed from Low to High
  • Affected Version changed from 1.0.4 to git development version
  • File gdb.txtMagnifier added
  • % Done changed from 0 to 20

Confirmed, triaged.
Version set to git master.
Setting priority "high".

bt attached.

#4 Updated by Simon Spannagel almost 5 years ago

(10:59:37) hanatos: _smn, i tried reproducing that bug, but didn't succeed. 100% working here :(
(11:00:06) hanatos: but i ran dt through valgrind and fixed something else. possible that it's related, memory corruption can have most random effects.
(11:08:12) Bostik: does valgrind do real threading now? it used to serialize everything
(11:08:42) hanatos: i think it still does
(11:09:35) Bostik: in that case it would hide thread-related races, because there wouldn't be any races
(11:10:20) hanatos: i couldn't crash it with or without
(11:10:33) hanatos: plus, the important bits are in one thread
(11:10:43) hanatos: import is blocking if you call from cmdline
(11:10:54) Bostik: ah
(11:11:14) _smn: hm, that thing is really strange
(11:13:50) hanatos: there was some possible char * thing that pointed to freed memory

#5 Updated by Lewis Collard almost 5 years ago

hanatos' fix probably fixed some other bug, but not this one. :) Same behaviour in git master, pulled just now.

#6 Updated by Igor Kuzmin almost 5 years ago

I can confirm this issue, happens with darktable from current git master on Linux. Noticed it with image from bug #8880, you can find my backtrace there.

#7 Updated by Lewis Collard almost 5 years ago

To confirm that it's not D1-specific, this raw file causes the same behaviour (a crash, but inconsistently) while trying to open the file. Git master from a couple of days ago. Backtrace attached.

The file (from a Canon Powershot A710IS, modified CHDK firmware):

#8 Updated by Pascal de Bruijn over 4 years ago

I just did some tests with CRW9943.DNG and DSC_0081.NEF and I wasn't able to reproduce any crash or other weird behavior using current Darktable git master (1.1~rc2 plus a few patches) on Ubuntu Precise AMD64.

Could you please retest this on your end? You can get ready-to-go git master packages from my Darktable-Unstable-PPA (don't forgot to install the darktable-dbg package as well).

If you are able to reproduce a crash, an updated backtrace might be useful.

#9 Updated by Lewis Collard over 4 years ago

Apologies for the delay in getting back to you. I'll confirm that this bug is no longer present for Nikon D1 NEF files in Darktable git (even with embedded thumbnails enabled). Thanks!

#10 Updated by Pascal de Bruijn over 4 years ago

  • Status changed from Triaged to Fixed
  • % Done changed from 20 to 100
  • Affected Version changed from git development version to 1.0.5

Also available in: Atom PDF