Bug 415882 - DigiKam 6.4 crashes on processing a large number of new HEIC/HEIF files
Summary: DigiKam 6.4 crashes on processing a large number of new HEIC/HEIF files
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Engine (show other bugs)
Version: 6.4.0
Platform: Appimage Linux
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-05 00:13 UTC by TahomaSoft
Modified: 2020-01-09 05:43 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.0.0
Sentry Crash Report:


Attachments
Two runs of digikam with output captured by typescript. 1) no GDB; 2) with GDB and backtrace. (369.94 KB, application/octet-stream)
2020-01-05 00:17 UTC, TahomaSoft
Details

Note You need to log in before you can comment on or make changes to this bug.
Description TahomaSoft 2020-01-05 00:13:04 UTC
SUMMARY


STEPS TO REPRODUCE
1. Have a lot of new HEIC/HEIF files to process
2. Start digikam
3. Use digikam
4. (not always required step) try to preview the new images that have been/are being processed

OBSERVED RESULT

Digikam crashes with several errors, the last of which are 'too many files open'


EXPECTED RESULT

digikam doesn't crash

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora 31 (but testing app image digikam-6.4.0-x86-64.appimage)

(available in About System)
KDE Plasma Version: 5.17.4
KDE Frameworks Version: 5.64.0
Qt Version: 5.12.5

ADDITIONAL INFORMATION
64-bit
12 x Intel Core i7-5930k CPU @ 3.5 GHz
62.7 GiB of RAM

I can run digikam iteratively and make progress processing the new HEIC/HEIF files.  

By that I mean that it will get through a bunch before it crashes.  Next run will get through more before it crashes again.

I am attaching two typescripts from two successive runs.  First was not done using GDB.  The second was done using GDB and has a backtrace at the end.
Comment 1 TahomaSoft 2020-01-05 00:17:06 UTC
Created attachment 124896 [details]
Two runs of digikam with output captured by typescript. 1) no GDB; 2) with GDB and backtrace.

Tar file (gz compression: tar cvzf .... )
Comment 2 caulier.gilles 2020-01-05 06:12:53 UTC
*** This bug has been marked as a duplicate of bug 414016 ***
Comment 3 caulier.gilles 2020-01-05 06:16:42 UTC
*** This bug has been marked as a duplicate of bug 414028 ***
Comment 4 Maik Qualmann 2020-01-05 07:22:17 UTC
Gilles has now reduced the debug output. However, this message "Creating pipes for GWakeup: Too many open files" comes from Gnome and is also a discussed bug with other programs.

Maik
Comment 5 caulier.gilles 2020-01-05 21:39:23 UTC
digiKam AppImage 7.0.0-beta2 64 bits is updated with last changes to reduce QtLogging data stream at run-time.

File can be downloaded at this place for testing :

https://files.kde.org/digikam/

Can you reproduce the problem with this version ?

Thanks in advance

Gilles Caulier
Comment 6 caulier.gilles 2020-01-07 08:39:09 UTC
Git commit bd7adde1afc349cad5001687846ee31af766d0c7 by Gilles Caulier.
Committed on 07/01/2020 at 08:37.
Pushed by cgilles into branch 'master'.

digiKam AppImage: Drop Qt core debug traces dispatched by Qt Logging categories
Related: bug 414016, bug 414028

M  +3    -0    project/bundles/appimage/data/AppRun

https://invent.kde.org/kde/digikam/commit/bd7adde1afc349cad5001687846ee31af766d0c7
Comment 7 caulier.gilles 2020-01-08 08:26:52 UTC
Git commit e613bc900c58144256e6d24e463217dabe76e495 by Gilles Caulier.
Committed on 08/01/2020 at 08:22.
Pushed by cgilles into branch 'master'.

This is a mess: some qWarning(), qInfo(), qCritical() messages are not wrapped in litteral debug spaces as expected
and are printed as "unknown". To disable these messages, the right keyword is "default" (it's logic of course!)
Now AppImage do not export the huge warning strings from Qt core in log files. ouf...
Related: bug 414028, bug 414016

M  +1    -1    project/bundles/appimage/data/AppRun

https://invent.kde.org/kde/digikam/commit/e613bc900c58144256e6d24e463217dabe76e495