| Summary: | Unexpected crash on rescan - Latest 5.5. AppImage | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Andrius <aegoreev> |
| Component: | Metadata-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | caulier.gilles |
| Priority: | NOR | ||
| Version: | 5.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | Appimage | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 7.3.0 | |
| Sentry Crash Report: | |||
It crash in Exiv2 shared library when a file is open for reading in /media/data/Family Pictures/2016/2016-12/20161203/ Can you identify which file is relevant of this crash ? Do you use non latin1 characters in file name ? Gilles Caulier (In reply to caulier.gilles from comment #1) > It crash in Exiv2 shared library when a file is open for reading in > /media/data/Family Pictures/2016/2016-12/20161203/ > > Can you identify which file is relevant of this crash ? > > Do you use non latin1 characters in file name ? > > Gilles Caulier Here is what I did: ffmpeg -i '/media/data/Family Pictures/2016/2016-12/20161203/20161203_142535.mp4' -c:v libx264 -crf 23 -c:a aac -strict experimental -q:a 100 -map_metadata 0 '/media/data/Family Pictures/2016/2016-12/20161203/20161203_142535_x264.mp4' You can see both the source file and the output file in the command. There is no non-latin symbols in the file names. digiKam detected new file 20161203_142535_x264.mp4 in the directory and crashed. FFmpeg encoding was still in progress. This is a special use case, with Exiv2. First Exiv2 is very sensible with video files. Video parser needs again optimisations. Second, the way to parse a file under construction is not an expected situation that Exiv2 have tested. The Exiv2 code need certainly some wrap around this situation to prevent a crash. At least, a C++ exception must be generated, not a crash. C++ exception will be catch by digiKam. Please report this use case to Exiv2 bugzilla. Best Gilles Caulier (In reply to caulier.gilles from comment #3) > This is a special use case, with Exiv2. > > First Exiv2 is very sensible with video files. Video parser needs again > optimisations. > > Second, the way to parse a file under construction is not an expected > situation that Exiv2 have tested. > > The Exiv2 code need certainly some wrap around this situation to prevent a > crash. At least, a C++ exception must be generated, not a crash. C++ > exception will be catch by digiKam. > > Please report this use case to Exiv2 bugzilla. > > Best > > Gilles Caulier What exiv2 command or API call does digiKam use when a new file detected in the collection? A lots of API calls through Digikam::DMetadata class : https://cgit.kde.org/digikam.git/tree/libs/dmetadata Gilles Caulier Not reproducible with digiKam 7.3.0 and Exiv2 0.27.4 |
I started compressing an mp4 file saving the output to the original directory. digiKam detected a change, trigered rescan and crashed [New Thread 0x7fff117fa700 (LWP 21025)] [Thread 0x7fff087f8700 (LWP 20961) exited] [Thread 0x7fff117fa700 (LWP 21025) exited] digikam.general: Detected change, triggering rescan of "/media/data/Family Pictures/2016/2016-12/20161203/" digikam.database: Starting scan! [Switching to Thread 0x7fffdf19a700 (LWP 20566)] Thread 3 "Digikam::ScanCo" hit Catchpoint 1 (exception thrown), 0x00007fffebe788bd in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (gdb) bt #0 0x00007fffebe788bd in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x00007ffff5dccfb5 in Exiv2::ImageFactory::open (path=..., useCurl=<optimized out>) at /b/ext_exiv2/ext_exiv2-prefix/src/ext_exiv2/src/image.cpp:834 #2 0x00007ffff680dce1 in Digikam::MetaEngine::load (this=this@entry=0x7fffd8084db0, filePath=...) at /b/dktemp/digikam-master/core/libs/dmetadata/metaengine.cpp:278 #3 0x00007ffff68564c6 in Digikam::DMetadata::load (this=this@entry=0x7fffd8084db0, filePath=...) at /b/dktemp/digikam-master/core/libs/dmetadata/dmetadata.cpp:96 #4 0x00007fffed4caa8a in Digikam::ImageScanner::loadFromDisk (this=this@entry=0x7fffdf1998f0) at /b/dktemp/digikam-master/core/libs/database/item/imagescanner.cpp:1553 #5 0x00007fffed4cac20 in Digikam::ImageScanner::newFile (this=this@entry=0x7fffdf1998f0, albumId=1006) at /b/dktemp/digikam-master/core/libs/database/item/imagescanner.cpp:289 #6 0x00007fffed40eb5e in Digikam::CollectionScanner::scanNewFile (this=this@entry=0x7fffdf199cf0, info=..., albumId=1006) at /b/dktemp/digikam-master/core/libs/database/collection/collectionscanner.cpp:1259 #7 0x00007fffed41077b in Digikam::CollectionScanner::scanAlbum (this=this@entry=0x7fffdf199cf0, location=..., album=...) at /b/dktemp/digikam-master/core/libs/database/collection/collectionscanner.cpp:1087 #8 0x00007fffed41258c in Digikam::CollectionScanner::partialScan (this=this@entry=0x7fffdf199cf0, albumRoot=..., album=...) at /b/dktemp/digikam-master/core/libs/database/collection/collectionscanner.cpp:687 #9 0x00007fffed41269c in Digikam::CollectionScanner::partialScan (this=this@entry=0x7fffdf199cf0, filePath=...) at /b/dktemp/digikam-master/core/libs/database/collection/collectionscanner.cpp:613 #10 0x00007ffff7518385 in Digikam::ScanController::run (this=0x7ffff7dd5660 <_ZZN7Digikam12_GLOBAL__N_113Q_QGS_creator13innerFunctionEvE6holder>) at /b/dktemp/digikam-master/core/libs/database/utils/scancontroller.cpp:750 #11 0x00000031e02aef49 in ?? () from /tmp/.mount_sFgLxy/usr/lib/libQt5Core.so.5 #12 0x00007ffff5a4e6ba in start_thread (arg=0x7fffdf19a700) at pthread_create.c:333 #13 0x00007fffeb60982d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb)