Hi all,
I’m posting here because although the darktable/development page says to post bug reports to the mailing list, the linked-to contact page suggests posting here first, leaving mailing lists as a last resort. If I’ve misinterpreted that, please just say so and I’ll send an email version.
There are a lot of moving pieces to this puzzle, and not all of them are in darktable, but I’ll start there because I have crash reports and have collected debug trace files, which might prove useful.
I’m afraid that I don’t have a quick-repeat error, either. The problem does seem to be repeatable in my setup, but it happens some thousand-or-so photos into an import with a folder that contains usually between 2000 and 5000 photos, along with two sets of matching .xmp files (the ones that darktable is creating, of the form photoNum.NEF.xmp and the ones that Lightroom Classic creates, of the form photoNum.xmp). My partner has just returned from a trip with about 4TiB of photos, mostly 50MB NEFs from a Nikon D810…
The computer is a 2019 5K iMac-27 with 32G RAM running Ventura 13.1.
Darktable -v says:
this is darktable 4.2.0
copyright (c) 2009-2022 johannes hanika
https //github.com/darktable-org/darktable/issues/new/choose
compile options:
bit depth is 64 bit
normal build
SSE2 optimized codepath enabled
OpenMP support enabled
OpenCL support enabled
Lua support enabled, API version 9.0.0
Colord support disabled
gPhoto2 support enabled
GraphicsMagick support enabled
ImageMagick support disabled
libavif support enabled
libheif support enabled
libjxl support enabled
OpenJPEG support enabled
OpenEXR support enabled
WebP support enabled
Additional complicating factors:
The photo storage is on my file server, which is serving the houshold macs with samba (4.13.17_4 installed from FreeBSD’s ports tree, built from source with some non-standard (simplified) build options. The file server is running FreeBSD 13-stable, with all-ZFS pools. The Samba configuration has all of the usual macOS-friendly switches turned on, per the documentation, but either macOS or samba or both are (IMO) not best of friends, because both darktable (not on this occasion) and Lightroom Classic seem to have a tendency to provoke the file system mounts to spontaneously disconnect. Touch-wood: this has not happened since I turned up the debugging log level this morning…
The assertion that (eventually) fails is (according to the -d all log):
dyld[14674] Assertion failed (child->full()), function splitChild, file BTree.h, line 187.
According to the crash dump this is: (I’m happy to post more of the crash dump if useful)
Crashed Thread: 11 gphoto_update
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace DYLD, Code 9
Assertion failed: (child->full()), function splitChild, file BTree.h, line 187.
The stack trace for that thread (or any others) is available on request, but it is abort() called from lsl BTree clear() called from libltdl.7 vm_open() called from gphoto2_port gp_port_info_list_load() called from libdarktable dt_camctl_update_cameras(). I’m eliding it because I think that the forum software is interpreting all of the C++ types as URLs, and it says that I can only post four, even though there was only the one above from the --version output…
I am pleased to report that darktable’s stored state seems to be incredibly stable (probably thanks to being in an SQL database) and so simply restarting and picking up the import process where it left off does seem to work. So I’m making progress: it’s just taking a bit more hand-holding than I would have hoped.
I read a suggestion in another discussion that running darktable under lldb could be useful for poking around the problem, but I’m afraid that Apple isn’t down with that, probably because my macOS is up-to-date and I’m running from a version installed from a downloaded dmg, rather than one I’ve compiled myself. Lldb complains that it can’t attach to the process. I haven’t had much luck with builds from MacPorts, but I’m happy to give that another go, if it’ll help.
Clues, best-practices, ideas or fixes would be appreciated.
Cheers,
Andrew