segmentation fault when exporting website-gallery
A Debian user reports (and I confirmed with 1.2.1)
-> Open darktable -> 'import' a new folder of images -> 'select' all -> 'export selected' --> choose "website gallery" as 'target storage' --> select a new directory for export target directory will change to e.g. "/tmp/darktable/foo/$(FILE_NAME)" --> click on 'export' Result: * darktable starts exporting and eventually crashes * the target directory (e.g. "/tmp/darktable/foo/") will stay empty * the directory where darktable has been launched, will contain weird files, e.g. $ find . ./x ./x-thumb.jpg ./x.jpg another time i got files like: $ ls ? <div><a class="dia" rel="lightbox[viewer]" title="??.jpg - " href="??.jpg"><span>< ?? ??-thumb.jpg ??.jpg (yes, that's filenames looking like HTML code!!)
For more details, and a backtrace, see
#1 Updated by Jörn Nettingsmeier about 6 years ago
i can confirm this behaviour with 1.2.2. it also exists in the current 1.3 git snapshot that's available from opensuse contributor toganm.
it appears the root of the bug is in the file chooser dialog: if you use it to select a base directory, weird characters appear in file and directory names, and the export process ultimately fails.
there is a workaround, which is described in the debian bug tracker thread: if you type the export base dir rather than using the file chooser, the export succeeds.
#2 Updated by Christian Kanzian almost 6 years ago
- % Done changed from 0 to 10
- Status changed from New to Confirmed
I can confirm this with current 1.3+1376~g3e7e96e git version too.
if you use the file chooser dialog, the $(FILE_NAME) variable is appended automaticaly. dt crashes during export and you will find a folder and 2 files with scrambled file names in your home.
removing $(FILE_NAME) from the path by hand avoid this crash as descripted.
To me $(FILE_NAME) makes no sense in the path for a web gallery.
Changing src/imageio/storage/gallery.c line 96 from:
snprintf(composed, DT_MAX_PATH_LEN, "%s/$(FILE_NAME)", dir);
snprintf(composed, DT_MAX_PATH_LEN, "%s/", dir);
avoids this behaviour.
But if a user type in $(FILE_NAME) he also will endup with a crash. I don't know how to fix it, because i have no coding skills.
#3 Updated by Tobias Ellinghaus almost 6 years ago
- bitness set to 64-bit
- Affected Version changed from 1.2 to git development version
- % Done changed from 10 to 20
- Target version set to Candidate for next minor release
- Assignee set to Tobias Ellinghaus
- Status changed from Confirmed to Triaged
If noone is faster than me I will look into this. It seems there are several things going on that are not correct.