Summary: | Digikam crashed during search for duplicates | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | cirdan52 |
Component: | Searches-Similarity | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | caulier.gilles, cirdan52, oleg.atamanenko+kde |
Priority: | NOR | ||
Version: | 1.4.0 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 1.7.0 | |
Sentry Crash Report: | |||
Attachments: |
output of massif
New crash information added by DrKonqi New crash information added by DrKonqi New crash information added by DrKonqi |
Description
cirdan52
2010-09-04 05:26:25 UTC
Crash appear in AlbumManager class... Gilles Caulier #12 0xb4bbd56f in std::terminate() () from /usr/lib/libstdc++.so.6 #13 0xb4bbd73a in __cxa_rethrow () from /usr/lib/libstdc++.so.6 #14 0xb586b39b in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #15 0x0824c6d7 in Digikam::AlbumManager::signalAllAlbumsLoaded (this=0x8582f60) An exception is thrown from a slot connected to this signal. - console output should indicate the type of exception - running under gdb and setting a catchpoint with "catch throw" should stop when throwing, allowing a nice backtrace for this point On Saturday, September 04, 2010 06:32:01 am Marcel Wiesweg wrote:
> https://bugs.kde.org/show_bug.cgi?id=250134
>
>
>
>
>
> --- Comment #2 from Marcel Wiesweg <marcel wiesweg gmx de> 2010-09-04
> 12:31:59 --- #12 0xb4bbd56f in std::terminate() () from
> /usr/lib/libstdc++.so.6 #13 0xb4bbd73a in __cxa_rethrow () from
> /usr/lib/libstdc++.so.6
> #14 0xb586b39b in QMetaObject::activate(QObject*, QMetaObject const*, int,
> void**) () from /usr/lib/libQtCore.so.4
> #15 0x0824c6d7 in Digikam::AlbumManager::signalAllAlbumsLoaded
> (this=0x8582f60)
>
> An exception is thrown from a slot connected to this signal.
> - console output should indicate the type of exception
> - running under gdb and setting a catchpoint with "catch throw" should
> stop when throwing, allowing a nice backtrace for this point
Not quite sure of how to use gdb. This is the first bug I've reported. I ran
gdb in the console gdb /usr/bin/digikam I didn't see any output etc. And how
do you set the catchpoint with gdb etc?
Look there : http://www.digikam.org/drupal/contrib Gilles Caulier On Saturday, September 04, 2010 10:13:24 am Gilles Caulier wrote:
> https://bugs.kde.org/show_bug.cgi?id=250134
>
>
>
>
>
> --- Comment #4 from Gilles Caulier <caulier gilles gmail com> 2010-09-04
> 16:13:23 --- Look there : http://www.digikam.org/drupal/contrib
>
> Gilles Caulier
Program received signal SIGABRT, Aborted.
0xffffe424 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe424 in __kernel_vsyscall ()
#1 0xb51ae7ff in raise () from /lib/libc.so.6
#2 0xb51b0140 in abort () from /lib/libc.so.6
#3 0xb53ec7dd in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib/libstdc++.so.6
#4 0xb53ea533 in ?? () from /usr/lib/libstdc++.so.6
#5 0xb53ea56f in std::terminate() () from /usr/lib/libstdc++.so.6
#6 0xb53ea73a in __cxa_rethrow () from /usr/lib/libstdc++.so.6
#7 0xb609839b in QMetaObject::activate(QObject*, QMetaObject const*, int,
void**) ()
from /usr/lib/libQtCore.so.4
#8 0x0824c6d7 in Digikam::AlbumManager::signalAllAlbumsLoaded
(this=0x8581928)
at /usr/src/debug/digikam-1.4.0/build/digikam/albummanager.moc:257
#9 0x0826072a in Digikam::AlbumManager::startScan (this=0x8581928)
at /usr/src/debug/digikam-1.4.0/digikam/albummanager.cpp:1090
#10 0x082ab65a in Digikam::DigikamApp::DigikamApp (this=0x85980c0,
__in_chrg=<value optimized out>, __vtt_parm=<value optimized out>)
at /usr/src/debug/digikam-1.4.0/digikam/digikamapp.cpp:248
#11 0x0836ae7a in main (argc=Cannot access memory at address 0x27fe
) at /usr/src/debug/digikam-1.4.0/digikam/main.cpp:172
(gdb)
I see, digikam uses up all memory. Chances are it is std::bad_alloc thrown, you'll see that in the console. To set the catchpoint in gdb, the command is "catch throw". If it is really using up memory, it will be more interesting to see where the memory is used. Running "valgrind --tool=massif digikam" will run digikam, albeit very slow, watching its memory usage and producing an output file massif.out.xy. On Saturday, September 04, 2010 10:48:20 am Marcel Wiesweg wrote:
> https://bugs.kde.org/show_bug.cgi?id=250134
>
>
>
>
>
> --- Comment #6 from Marcel Wiesweg <marcel wiesweg gmx de> 2010-09-04
> 16:48:20 --- I see, digikam uses up all memory. Chances are it is
> std::bad_alloc thrown, you'll see that in the console.
> To set the catchpoint in gdb, the command is "catch throw".
>
> If it is really using up memory, it will be more interesting to see where
> the memory is used. Running "valgrind --tool=massif digikam" will run
> digikam, albeit very slow, watching its memory usage and producing an
> output file massif.out.xy.
You need to attach the file using the "Add an attachment" link on this web page, sending attachments by mail will not work. Created attachment 52167 [details]
output of massif
Marcel, Do you see the trace in #9 ? Gilles Caulier Yes. It stops somewhere at 15MB memory usage, that should be early in the startup. I dont see anything related there. Created attachment 52359 [details]
New crash information added by DrKonqi
digikam (1.4.0) on KDE Platform 4.5.2 (KDE 4.5.2) using Qt 4.7.0
- What I was doing when the application crashed:
I tried to update fingerprint database, but digikam crashed after several minutes.
-- Backtrace (Reduced):
#8 0xb68b8880 in Digikam::LoadSaveThread::run (this=0xbfd7660) at /home/uthark/Download/src/digikam-1.4.0/libs/threadimageio/loadsavethread.cpp:116
#9 0xb68faa66 in Digikam::DynamicThreadPriv::run (this=0xa46a830) at /home/uthark/Download/src/digikam-1.4.0/libs/threads/dynamicthread.cpp:237
[...]
[...]
[...]
[...]
Crash is there : http://lxr.kde.org/source/extragear/graphics/digikam/libs/threadimageio/loadsavethread.cpp#116 Gilles Caulier Created attachment 52432 [details]
New crash information added by DrKonqi
digikam (1.5.0) on KDE Platform 4.5.2 (KDE 4.5.2) using Qt 4.7.0
- What I was doing when the application crashed:
Looking for 100% duplicates, took 6 hrs to get to 100% and then it started using up memory, no thumbnails were displayed. It then terminated without a crash. I tried it a second time which resulted in a crash
-- Backtrace (Reduced):
#7 0xb47b8d99 in ycc_rgb_convert (cinfo=0xa3c35b48, input_buf=0x7e2ed9c8, input_row=<value optimized out>, output_buf=0xa3c35b44, num_rows=<value optimized out>) at jdcolor.c:149
#8 0xb47c1a5c in sep_upsample (cinfo=0xa3c35b48, input_buf=0x7e2edf2c, in_row_group_ctr=0x7e2edf58, in_row_groups_avail=1, output_buf=0xa3c35b40, out_row_ctr=0xa3c35acc,
out_rows_avail=<value optimized out>) at jdsample.c:129
#9 0xb47bd44b in process_data_simple_main (cinfo=0xa3c35b48, output_buf=0xa3c35b40, out_row_ctr=0xa3c35acc, out_rows_avail=1) at jdmainct.c:367
#10 0xb47b5a30 in jpeg_read_scanlines (cinfo=0xa3c35b48, scanlines=0xa3c35b40, max_lines=1) at jdapistd.c:173
#11 0xb6a1916f in Digikam::loadJPEGScaled (image=..., path=..., maximumSize=256) at /usr/src/debug/digikam-1.5.0/libs/jpegutils/jpegutils.cpp:223
It crash in libjpeg. It can be a binary uncompatibility between digiKam and libjpeg installed to your computer. Check your packages. Gilles Caulier I have 2 libjpeg libraries: libjpeg6 6.2.0-3.1 libjpeg8 8.01-2.1.1 This is the problem... only libjpeg version 8 must be installed on your system Gilles Caulier Google takes issue with not having libjpeg6, their chrome browser needs 6. Created attachment 52452 [details]
New crash information added by DrKonqi
digikam (1.5.0) on KDE Platform 4.5.2 (KDE 4.5.2) using Qt 4.7.0
- What I was doing when the application crashed:
Removed libjpeg6, crashed again.
Observation: It seems to me that the database is getting corrupted. The only way for me to get it ro run again is to delete the database entirely , restart and then just select a few of the directories instead of the entire album.
-- Backtrace (Reduced):
#15 0xb69679c5 in CPGFImage::SetHeader (this=0xa3a48974, header=..., flags=0 '\000', userData=0x0, userDataLength=0) at /usr/src/debug/digikam-1.5.0/libs/3rdparty/libpgf/PGFimage.cpp:600
#16 0xb696f587 in Digikam::writePGFImageData (img=..., data=..., quality=0) at /usr/src/debug/digikam-1.5.0/libs/threadimageio/pgfutils.cpp:116
#17 0xb694500a in Digikam::ThumbnailCreator::storeInDatabase (this=0x0, info=..., image=...) at /usr/src/debug/digikam-1.5.0/libs/threadimageio/thumbnailcreator.cpp:536
#18 0xb6949d18 in Digikam::ThumbnailCreator::load (this=0x9165c10, path=...) at /usr/src/debug/digikam-1.5.0/libs/threadimageio/thumbnailcreator.cpp:201
#19 0xb6953c7a in Digikam::ThumbnailLoadingTask::execute (this=0xb76b530) at /usr/src/debug/digikam-1.5.0/libs/threadimageio/thumbnailtask.cpp:133
digiKam 1.6.0 is out: http://www.digikam.org/drupal/node/550 Please update and check if this entry still valid. Thanks in advance Gilles Caulier I cannot reproduce this bug on the last version 1.6.0 under Archlinux. I guess, it is fixed. |