Gthumb crashes when trying to open files exported by Darktable

Bug #1943586 reported by Ben Aceler
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
gthumb (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Steps to reproduce: export a file from darktable (I attached one). Open it.

$ gthumb 0002.jpg
terminate called after throwing an instance of 'std::out_of_range'
  what(): basic_string::at: __n (which is 19) >= this->size() (which is 19)
Аварийный останов (стек памяти сброшен на диск)

As far as I can say from "basic_string" thing, EXIF or XMP tags are broken. Maybe it's a bug of Darktable, but gthumb shoudn't crash anyways.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gthumb 3:3.8.0-2.1build1
ProcVersionSignature: Ubuntu 5.4.0-84.94-generic 5.4.133
Uname: Linux 5.4.0-84-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.18
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Tue Sep 14 15:29:41 2021
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=ru_RU.UTF-8
 SHELL=/bin/bash
SourcePackage: gthumb
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Ben Aceler (aceler) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gthumb (Ubuntu):
status: New → Confirmed
Revision history for this message
kelvalok (kelvalok) wrote :

It also happens in gwenview for a file exported from Darktable... same error.

$gwenview FXT21038_0.jpg
org.kde.kdegraphics.gwenview.lib: Unresolved mime type "image/x-mng"
org.kde.kdegraphics.gwenview.lib: Unresolved raw mime type "image/x-nikon-nrw"
org.kde.kdegraphics.gwenview.lib: Unresolved raw mime type "image/x-samsung-srw"
terminate called after throwing an instance of 'std::out_of_range'
  what(): basic_string::at: __n (which is 19) >= this->size() (which is 19)
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = gwenview path = /usr/bin pid = 24875
KCrash: Arguments: /usr/bin/gwenview FXT21038_0.jpg
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi

[1]+ Aturat gwenview FXT21038_0.jpg

5.11.0-37-generic #41-Ubuntu SMP
kubunut 21.04

Revision history for this message
Viatour Luc (lviatour) wrote :

I upgraded from Ubuntu 21.04 to 21.10 and the bug is still present.
On the mageia distribution they seem to have fixed the bug that would come from lib64exiv2:
https://bugs.mageia.org/show_bug.cgi?id=29440

The crash is in Gthumb and gwenview

Revision history for this message
Alexei Kojenov (alexei-kojenov) wrote :

I was having the same issue in Kubuntu 20.04. The issue went away after I downgraded libexiv2 from version 0.27.2-8ubuntu2.6 to version 0.27.2-8ubuntu2 as follows:

sudo apt-get install libexiv2-27=0.27.2-8ubuntu2

Revision history for this message
Vitalii (acvarium) wrote :

Will this be fixed in this century? I slowly moved from Ubuntu 20.04 to 21.10. And in all of those versions, issue persisted. Some time ago I could just downgrade the version of libexiv2. Now the previous version is no longer accessible from repo. I can not use my favorite image viewer, Gthumb. It just crashes on all of my photos exported from Darktable.

Revision history for this message
ppotamusmaximus (ppotamusmaximus) wrote :

The issue is around libexiv2.

How I solve it:
I rename (yes, desperate try) the library libexiv2.so.0.27.3 to undo the symbolic link and recover the lib if this try fails -or other program crashes-.

In my Ubuntu the library is placed at: /usr/lib/x86_64-linux-gnu

It works for my Ubuntu 21.10 with gThumb 3.11.2 installed from Ubuntu.
I reinstall gThumb to "repeat" the process: gThumb redo the symbolic link and crashes again, I undo the symbolic link and it works.

Other applications are working fine after (Darktable of course, Shotwell, etc.) nothing weirdz detected.

I expect that it works for you.

Revision history for this message
Ben Aceler (aceler) wrote :

Upstream claims it's fixed in libexiv2 v0.27.5: https://github.com/Exiv2/exiv2/issues/2011

Revision history for this message
ppotamusmaximus (ppotamusmaximus) wrote :

I confirm it, right now I was checking it (https://www.exiv2.org/) Thank you Ben!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.