darktable crash while import of folder

[bilddateien]

Don't know if this is related to https://github.com/darktable-org/darktable/issues/7641 since no more details are given there

Preface: I have two folders in my archive with around 150 and 225 images, mainly in jpg format. Those were already imported in darktable in previous versions - no issues until now.

I decided to clean up some filenames (replacing a space by a _). For this I removed those files from the darktable database by the relevant lighttable option, fixed the filenames (both image and .xmp) and then tried to reimport the folder.

Darktable crashed while import.

After reading this https://github.com/darktable-org/darktable/issues/7691#issuecomment-754891186 I tried on a second machine (synchonized archive and dt profile) - same result.

Describe the bug

darktable crashes when importing image folder with mainly jpg images with accompanying .xmp files produced by darktable

To Reproduce

1. Go to 'lighttable'
2. Click on 'import folder'
3. move to target folder, disable all options (Metadata, recursive and ignore jpg)
4. See error

Expected behavior

dt should simply import the (missing) images from the folder

Screenshots

no screenshots, backtraces from two machines attached darktable_bt_DQJNW0.txt darktable_bt_TDV1W0.txt

Platform (please complete the following information): darktable from OBS

~$ darktable --version
this is darktable 3.4.0
copyright (c) 2009-2020 johannes hanika
darktable-dev@lists.darktable.org

compile options:
  bit depth is 64 bit
  normal build
  SSE2 optimized codepath enabled
  OpenMP support enabled
  OpenCL support enabled
  Lua support enabled, API version 6.1.0
  Colord support enabled
  gPhoto2 support enabled
  GraphicsMagick support enabled
  ImageMagick support disabled
  OpenEXR support enabled

machine no. 1 - no openCL

System:
  Host: Rechner Kernel: 4.19.0-13-amd64 x86_64 bits: 64 compiler: gcc 
  v: 8.3.0 Desktop: Cinnamon 3.8.8 Distro: Debian GNU/Linux 10 (buster) 
Machine:
  Type: Desktop Mobo: ASUSTeK model: P8Z77-M v: Rev 1.xx serial: <filter> 
  UEFI: American Megatrends v: 2203 date: 12/18/2015 
CPU:
  Topology: Quad Core model: Intel Core i5-3570 bits: 64 type: MCP 
  arch: Ivy Bridge rev: 9 L2 cache: 6144 KiB 
  flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 27282 
  Speed: 1605 MHz min/max: 1600/3800 MHz Core speeds (MHz): 1: 1605 2: 1605 
  3: 1605 4: 1605 
Graphics:
  Device-1: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics 
  vendor: ASUSTeK P8H77-I driver: i915 v: kernel bus ID: 00:02.0 
  Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa 
  resolution: 1920x1200~60Hz 
  OpenGL: renderer: Mesa DRI Intel Ivybridge Desktop v: 4.2 Mesa 18.3.6 
  direct render: Yes 

machine no. 2 - also no openCL

System:    Host: carPC Kernel: 4.19.0-13-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: Cinnamon 3.8.8 
           Distro: Debian GNU/Linux 10 (buster) 
Machine:   Type: Desktop Mobo: ASRock model: J4205-ITX serial: <filter> UEFI: American Megatrends v: P1.30 date: 04/18/2017 
CPU:       Topology: Quad Core model: Intel Pentium J4205 bits: 64 type: MCP arch: Goldmont rev: 9 L2 cache: 1024 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 11980 
           Speed: 998 MHz min/max: 800/2600 MHz Core speeds (MHz): 1: 956 2: 929 3: 918 4: 996 
Graphics:  Device-1: Intel Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series Integrated Graphics vendor: ASRock 
           driver: i915 v: kernel bus ID: 00:02.0 
           Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel HD Graphics 505 (Broxton) v: 4.5 Mesa 18.3.6 direct render: Yes 

Additional context

Also tried to move the xmp away from the folder and import jpg only - same result

• Is the issue still present using an empty/new config-dir YES

[johnny-bit]

darktable_bt_DQJNW0.txt - this backtrace names a problemw ith dt_map_location_get_locations_by_path in sqlite_step... darktable_bt_TDV1W0.txt - this is very weird.

you say this happens on clean db?

can you share a file+xmp that causes issue?

[bilddateien]

Q1: I tried this with blank profile also just while writing the bug report, the backtraces are from before I did this with my working profile. So yes: with existing profile and with blank profile Q2: I'll try to reduce the above mentioned number of 150 or 225 images to a useful number and provide these - tomorrow ...

Btw: I tried to reimport a folder with few hundred raw images that were already imported (so obviously nothing to do for darktable) and had no issues. I first suspected it's the number of images ... but this alone seems not to be the case.

[bilddateien]

OK, here we go: I trashed profiles on both of my two computers mentioned above. I then started darktable from terminal darktable -d all. Then I imported the attached folder with 1 image accompanied by 1 xmp. After a few seconds darktable crashed. Backtraces per machine attached also.

Note that the xmp was generated in 2018 by what was then darktable latest stable (don't remember the exact version number)

2017-single.zip machine1_darktable_bt_V7VVW0.txt machine2_darktable_bt_4NJ2W0.txt

[bilddateien]

just tested: same with dt 3.5.0+484~g32dd67ac7

[phweyland]

dt crashes with your files. in exif.c (dt_exif_xmp_read) on if(multi_priority && multi_priority_iter != multi_priority.node().children().end()) reading Schuhschrank_S3640008.jpg.xmp

I'm a bit surprised to see an xmp beside a jpg. Normally the xmp data are embedded in jpg file, aren't they?

EDIT: without the xmp import works properly. EDIT2: the only operation in xmp is flip

[johnny-bit]

Not necessarily if one wants to process jpeg in darktable...

czw., 7 sty 2021 o 12:42 Philippe notifications@github.com napisał(a):

dt crashes with your files. in exif.c (dt_exif_xmp_read) on if(multi_priority && multi_priority_iter != multi_priority.node().children().end()) reading Schuhschrank_S3640008.jpg.xmp

I'm a bit surprised to see an xmp beside a jpg. Normally the xmp data are embedded in jpg file, isn't ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/7720#issuecomment-756065782, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRRKFNDTPXN7VMJW5IXLLDSYWMY5ANCNFSM4VYBUCTA .

-- Pozdrawiam, Hubert Kowalski

[TurboGit]

@bilddateien : Looking at this issue more deeply I see that the XMP is bogus. I think you've been using a dev version at some point, do you confirm ?

[bilddateien]

Not necessarily if one wants to process jpeg in darktable... czw., 7 sty 2021 o 12:42 Philippe notifications@github.com napisał(a): … dt crashes with your files. in exif.c (dt_exif_xmp_read) on if(multi_priority && multi_priority_iter != multi_priority.node().children().end()) reading Schuhschrank_S3640008.jpg.xmp I'm a bit surprised to see an xmp beside a jpg. Normally the xmp data are embedded in jpg file, isn't ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7720 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRRKFNDTPXN7VMJW5IXLLDSYWMY5ANCNFSM4VYBUCTA . -- Pozdrawiam, Hubert Kowalski

exactly - but in this case it's more about tagging - I manage all images in darktable

[bilddateien]

@bilddateien : Looking at this issue more deeply I see that the XMP is bogus. I think you've been using a dev version at some point, do you confirm ?

Schuhschrank_S3640008.jpg
atime    : 2021-01-07 10:24:47.983027489 +0100
mtime    : 2017-10-10 10:13:02.695036000 +0200
ctime    : 2021-01-07 10:23:19.936120686 +0100

Schuhschrank_S3640008.jpg.xmp
atime    : 2021-01-07 10:24:48.551020451 +0100
mtime    : 2018-03-30 17:01:06.419810000 +0200
ctime    : 2021-01-07 10:23:19.940120637 +0100

Since the xmp was last modified in March 2018 I do not assume that. I started to compile dev versions in spring of last year. Before I used PPA versions.