| Summary: | digikam crashes after resizing several pictures in a batch | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Ralph Moenchmeyer <rm> |
| Component: | Plugin-Bqm-Resize | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | andresbajotierra, freu_dich |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 0.4.0 | |
| Sentry Crash Report: | |||
| Attachments: |
standard start of digikam without valgrind
digikam started with valgrind DigiKam Started normal - Crash on KIPI resize when closing finished Window DigiKam Started with Valgrind - no Crash on KIPI resize when closing finished Window |
||
|
Description
Ralph Moenchmeyer
2009-04-26 17:24:44 UTC
Nothing suitable appears in the GDB backtrace. Can you run digiKam into valgrind and report console message here ? Command line to use is : valgrind --tool=memcheck --leak-check=full --error-limit=no digikam Gilles Caulier There are similar reports (similar backtrace too) on batch operations of kipi-plugins like bug 190273 and bug 189786 Thanks Created attachment 33191 [details]
standard start of digikam without valgrind
Created attachment 33192 [details]
digikam started with valgrind
I added two attachments : 1) one with the konsole output for a standard start of digikam 2) one with valgrid output In both cases I did the same. I choose two pictures and resized them in a batch. I the first case (without valgrind) digikam crashed when closing the resize dialog after a successfull resizing action for both images. However, digikam does not crash with valgrind being active. I hope you still may find some useful information in the output. (By the way: In both cases there are output lines saying that some (url) parent directories are not found. I checked for those directories. They do exist!) Other way to check : run Gwenview and look if it crash when you resize images in batch. plugins are the same between GWeniew and digiKam Gilles Caulier Look at this line: QObject: Do not delete object, 'unnamed', during its event handler! This usually points to a programming error where an object should be deleted with deleteLater(). To find out where it is done, install a breakpoint on qWarning(). Today I noticed that a colleague does not have the problem I have with digikam. She works on a machine with a very similar configuration compared to mine, but with digikam freshly installed. In my case the KDE4 packages including digikam have a relatively long update history. During my last update I changed from a package "kde4-digikam" to a package "digikam". This package change was a consequence of corresponding changes in the KDE 4.2 factory repository of Opensuse. Therefore, some minutes ago, I checked the digikam behaviour for a new user on my machine for whom I had to run through a first time configuration of digikam. Guess what ? No problems with resizing pictures afterwards for this user. So I renamed the configuration file ~/.kde4/share/config/digikamrc of my own account and restarted digikam. This, of course, led to the generation a new digikamrc file (which was considerably smaller than my old one). After that no problems anymore ! Comparing the digikamrc files I noticed a section "[resize Tool Dialog]" in the old configuration file which is not present in the new digikamrc-file. But there are also other differences. So, the problem is solved and the reason for it resided somewhere in the history of my digikamrc file. Therefore, I really do not know whether other users will stumble across a similar problem at all. Please, change the bug status to something that is appropriate for this situation. If you need more information or the contents of the digikamrc files, please, tell me. Additional note: The same solution worked by the way for gwenview. There, the batch modules for resizig did not even appear active in the respective menu. Deleting the gwenviewrc file resolved this problem, too. I have fixed some things about the batch plugins in SVN, maybe this fixed also these issues here. Can you test the latest SVN version of kipi-plugins? Andi Digicam crashes on Ubuntu 9.04 after batch-converting pictures with SIGSEGV after having finished conversion. Maybe this can be helpful: Anwendung: digiKam (digikam), Signal SIGSEGV [Current thread is 0 (LWP 10827)] Thread 14 (Thread 0xb25fab90 (LWP 10828)): #0 0xb7f06430 in __kernel_vsyscall () #1 0xb53590e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb545b2ed in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6 #3 0xb56479b2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #4 0x0828f319 in ?? () #5 0xb564696e in ?? () from /usr/lib/libQtCore.so.4 #6 0xb53554ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb544c49e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 13 (Thread 0xb1974b90 (LWP 10830)): #0 0xb7f06430 in __kernel_vsyscall () #1 0xb53590e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb545b2ed in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6 #3 0xb56479b2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #4 0xb7138d4a in Digikam::LoadSaveThread::run () from /usr/lib/libdigikamcore.so.1 #5 0xb564696e in ?? () from /usr/lib/libQtCore.so.4 #6 0xb53554ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb544c49e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 12 (Thread 0xb10e7b90 (LWP 10831)): #0 0xb7f06430 in __kernel_vsyscall () #1 0xb53590e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb545b2ed in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6 #3 0xb56479b2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #4 0xb7138d4a in Digikam::LoadSaveThread::run () from /usr/lib/libdigikamcore.so.1 #5 0xb564696e in ?? () from /usr/lib/libQtCore.so.4 #6 0xb53554ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb544c49e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 11 (Thread 0xae3f8b90 (LWP 10832)): #0 0xb7f06430 in __kernel_vsyscall () #1 0xb5359412 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb545b344 in pthread_cond_timedwait () from /lib/tls/i686/cmov/libc.so.6 #3 0xaf270ae3 in ?? () from /usr/lib/libxine.so.1 Thread 10 (Thread 0xad771b90 (LWP 10833)): #0 0xb7f06430 in __kernel_vsyscall () #1 0xb54447b1 in select () from /lib/tls/i686/cmov/libc.so.6 #2 0xaf29a7d6 in xine_usec_sleep () from /usr/lib/libxine.so.1 #3 0x00000000 in ?? () Thread 9 (Thread 0xacf70b90 (LWP 10834)): #0 0xb56306b0 in g_main_context_iteration@plt () from /usr/lib/libQtCore.so.4 #1 0xb5766457 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 #2 0xb573906a in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 #3 0xb57394aa in QEventLoop::exec () from /usr/lib/libQtCore.so.4 #4 0xb5643639 in QThread::exec () from /usr/lib/libQtCore.so.4 #5 0xaf2be20a in ?? () from /usr/lib/kde4/plugins/phonon_backend/phonon_xine.so #6 0xb564696e in ?? () from /usr/lib/libQtCore.so.4 #7 0xb53554ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #8 0xb544c49e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 8 (Thread 0xa875db90 (LWP 10840)): #0 0xb7f06430 in __kernel_vsyscall () #1 0xb5441ae7 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0xac769b19 in ?? () from /usr/lib/xine/plugins/1.26/xineplug_ao_out_alsa.so #3 0xb1a189fc in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 7 (Thread 0xac758b90 (LWP 10841)): #0 0xb7f06430 in __kernel_vsyscall () #1 0xb53590e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb545b2ed in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6 #3 0xaf281d8e in ?? () from /usr/lib/libxine.so.1 #4 0x00000001 in ?? () Thread 6 (Thread 0xa9fffb90 (LWP 10856)): #0 0xb7f06430 in __kernel_vsyscall () #1 0xb53590e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb545b2ed in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6 #3 0xb56479b2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #4 0xb7138d4a in Digikam::LoadSaveThread::run () from /usr/lib/libdigikamcore.so.1 #5 0xb564696e in ?? () from /usr/lib/libQtCore.so.4 #6 0xb53554ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb544c49e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 5 (Thread 0xabdffb90 (LWP 10862)): #0 0xb7f06430 in __kernel_vsyscall () #1 0xb53590e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb545b2ed in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6 #3 0xb56479b2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #4 0xb7138d4a in Digikam::LoadSaveThread::run () from /usr/lib/libdigikamcore.so.1 #5 0xb564696e in ?? () from /usr/lib/libQtCore.so.4 #6 0xb53554ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb544c49e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 4 (Thread 0xab5a7b90 (LWP 11562)): #0 0xb7f06430 in __kernel_vsyscall () #1 0xb53590e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb545b2ed in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6 #3 0xb56479b2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #4 0xb7138d4a in Digikam::LoadSaveThread::run () from /usr/lib/libdigikamcore.so.1 #5 0xb564696e in ?? () from /usr/lib/libQtCore.so.4 #6 0xb53554ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb544c49e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (Thread 0xaa9ffb90 (LWP 11563)): #0 0xb7f06430 in __kernel_vsyscall () #1 0xb53590e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb545b2ed in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6 #3 0xb56479b2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #4 0xb7138d4a in Digikam::LoadSaveThread::run () from /usr/lib/libdigikamcore.so.1 #5 0xb564696e in ?? () from /usr/lib/libQtCore.so.4 #6 0xb53554ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb544c49e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (Thread 0x9ef90b90 (LWP 11571)): #0 0xb7f06430 in __kernel_vsyscall () #1 0xb54447b1 in select () from /lib/tls/i686/cmov/libc.so.6 #2 0xb5718380 in ?? () from /usr/lib/libQtCore.so.4 #3 0xb564696e in ?? () from /usr/lib/libQtCore.so.4 #4 0xb53554ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb544c49e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (Thread 0xb4602920 (LWP 10827)): [KCrash Handler] #6 0xb5755261 in ?? () from /usr/lib/libQtCore.so.4 #7 0xb575452f in QSignalMapper::map () from /usr/lib/libQtCore.so.4 #8 0xb575465e in QSignalMapper::map () from /usr/lib/libQtCore.so.4 #9 0xb5754f2b in QSignalMapper::qt_metacall () from /usr/lib/libQtCore.so.4 #10 0xb5750ca8 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #11 0xb57510e0 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #12 0xb62c22b1 in QAbstractButton::clicked () from /usr/lib/libQtGui.so.4 #13 0xb5fed0b9 in ?? () from /usr/lib/libQtGui.so.4 #14 0xb5feed14 in ?? () from /usr/lib/libQtGui.so.4 #15 0xb5feefa6 in QAbstractButton::mouseReleaseEvent () from /usr/lib/libQtGui.so.4 #16 0xb5c62b43 in QWidget::event () from /usr/lib/libQtGui.so.4 #17 0xb5fecf5e in QAbstractButton::event () from /usr/lib/libQtGui.so.4 #18 0xb6097f20 in QPushButton::event () from /usr/lib/libQtGui.so.4 #19 0xb5c0be9c in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #20 0xb5c14b11 in QApplication::notify () from /usr/lib/libQtGui.so.4 #21 0xb682f94d in KApplication::notify () from /usr/lib/libkdeui.so.5 #22 0xb573aa3b in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #23 0xb5c13b7e in QApplicationPrivate::sendMouseEvent () from /usr/lib/libQtGui.so.4 #24 0xb5c8397e in ?? () from /usr/lib/libQtGui.so.4 #25 0xb5c82ca7 in QApplication::x11ProcessEvent () from /usr/lib/libQtGui.so.4 #26 0xb5cadc6a in ?? () from /usr/lib/libQtGui.so.4 #27 0xb4a10b88 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #28 0xb4a140eb in ?? () from /usr/lib/libglib-2.0.so.0 #29 0xb4a14268 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #30 0xb5766438 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 #31 0xb5cad365 in ?? () from /usr/lib/libQtGui.so.4 #32 0xb573906a in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 #33 0xb57394aa in QEventLoop::exec () from /usr/lib/libQtCore.so.4 #34 0xb573b959 in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 #35 0xb5c0bd17 in QApplication::exec () from /usr/lib/libQtGui.so.4 #36 0x082b4e3b in ?? () #37 0xb537e775 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #38 0x0808ddc1 in _start () Like I said above, this has been fixed already. Download latest kipi-plugins package (0.3.0) or install them from SVN. I will close this report now. Andi This problem have been fixed with kipi-plugins 0.3.0... Gilles Caulier Created attachment 33677 [details]
DigiKam Started normal - Crash on KIPI resize when closing finished Window
Created attachment 33678 [details]
DigiKam Started with Valgrind - no Crash on KIPI resize when closing finished Window
YES!!!! It is already fixed! :-) It doesn't crash in valgrind because it slows digiKam down, so the race-condition is not reproducable in there. The famous http://en.wikipedia.org/wiki/Heisenbug#Heisenbug effect. Andi |