Version: 1.3.0 (using KDE 4.5.0) OS: Linux If I click close button or select "Album — Exit [Ctrl-Q]", main window closes, but the application still remains in memory. Even if no other windows are opened. Then I need to kill it, because when I try to start it again, there are two copies of digikam in memory. Reproducible: Always Steps to Reproduce: 1. start digikam from konsole or 2. start digikam from anywhere. Then try to close it. Actual Results: 1. I don't see the command prompt again, need to Ctrl-C. or 2. open "top", "htop" or use "ps aux" or smth like this, see "digikam" in list. Expected Results: digikam should have disappeared from memory
Please start digikam, exit digikam and leave the process running. In another console find the PID of digikam with ps and start "gdb digikam PID". Inside gdb type "thread apply all bt" and paste the output here.
Here: (gdb) thread apply all bt Thread 6 (Thread 0xb287cb70 (LWP 24339)): #0 0x003f1416 in __kernel_vsyscall () #1 0x003fc4bc in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:169 #2 0x0466f8e7 in QWaitConditionPrivate::wait (this=0xa47adf8, mutex=0xa47adf4, time=4294967295) at thread/qwaitcondition_unix.cpp:88 #3 QWaitCondition::wait (this=0xa47adf8, mutex=0xa47adf4, time=4294967295) at thread/qwaitcondition_unix.cpp:160 #4 0x05e1c34a in Digikam::ParkingThread::run (this=0xa47ade8) at /build/buildd/digikam-1.3.0/libs/threads/threadmanager.cpp:101 #5 0x0466ed19 in QThreadPrivate::start (arg=0xa47ade8) at thread/qthread_unix.cpp:266 #6 0x003f7cc9 in start_thread (arg=0xb287cb70) at pthread_create.c:304 #7 0x06f6a73e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 5 (Thread 0xb207bb70 (LWP 24340)): #0 0x003f1416 in __kernel_vsyscall () #1 0x06f5be76 in *__GI___poll (fds=0x6ff3ff4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x07affc0b in g_poll () from /lib/libglib-2.0.so.0 #3 0x07af25bc in ?? () from /lib/libglib-2.0.so.0 #4 0x07af29c8 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #5 0x0479eea5 in QEventDispatcherGlib::processEvents (this=0x9b88af8, flags=...) at kernel/qeventdispatcher_glib.cpp:412 #6 0x0476ef29 in QEventLoop::processEvents (this=0xb207b2c0, flags=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at kernel/qeventloop.cpp:149 #7 0x0476f3aa in QEventLoop::exec (this=0xb207b2c0, flags=...) at kernel/qeventloop.cpp:201 #8 0x0466ba9e in QThread::exec (this=0x9bc31d0) at thread/qthread.cpp:490 #9 0x0466ed19 in QThreadPrivate::start (arg=0x9bc31d0) at thread/qthread_unix.cpp:266 #10 0x003f7cc9 in start_thread (arg=0xb207bb70) at pthread_create.c:304 #11 0x06f6a73e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 4 (Thread 0xb187ab70 (LWP 24341)): #0 0x003f1416 in __kernel_vsyscall () #1 0x06f5be76 in *__GI___poll (fds=0x6ff3ff4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x07affc0b in g_poll () from /lib/libglib-2.0.so.0 ---Type <return> to continue, or q <return> to quit---
Please press enter until there is no more output ;)
oh, sorry, I need to have a good sleep =\ (gdb) thread apply all bt Thread 6 (Thread 0xb287cb70 (LWP 24339)): #0 0x003f1416 in __kernel_vsyscall () #1 0x003fc4bc in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:169 #2 0x0466f8e7 in QWaitConditionPrivate::wait (this=0xa47adf8, mutex=0xa47adf4, time=4294967295) at thread/qwaitcondition_unix.cpp:88 #3 QWaitCondition::wait (this=0xa47adf8, mutex=0xa47adf4, time=4294967295) at thread/qwaitcondition_unix.cpp:160 #4 0x05e1c34a in Digikam::ParkingThread::run (this=0xa47ade8) at /build/buildd/digikam-1.3.0/libs/threads/threadmanager.cpp:101 #5 0x0466ed19 in QThreadPrivate::start (arg=0xa47ade8) at thread/qthread_unix.cpp:266 #6 0x003f7cc9 in start_thread (arg=0xb287cb70) at pthread_create.c:304 #7 0x06f6a73e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 5 (Thread 0xb207bb70 (LWP 24340)): #0 0x003f1416 in __kernel_vsyscall () #1 0x06f5be76 in *__GI___poll (fds=0x6ff3ff4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x07affc0b in g_poll () from /lib/libglib-2.0.so.0 #3 0x07af25bc in ?? () from /lib/libglib-2.0.so.0 #4 0x07af29c8 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #5 0x0479eea5 in QEventDispatcherGlib::processEvents (this=0x9b88af8, flags=...) at kernel/qeventdispatcher_glib.cpp:412 #6 0x0476ef29 in QEventLoop::processEvents (this=0xb207b2c0, flags=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at kernel/qeventloop.cpp:149 #7 0x0476f3aa in QEventLoop::exec (this=0xb207b2c0, flags=...) at kernel/qeventloop.cpp:201 #8 0x0466ba9e in QThread::exec (this=0x9bc31d0) at thread/qthread.cpp:490 #9 0x0466ed19 in QThreadPrivate::start (arg=0x9bc31d0) at thread/qthread_unix.cpp:266 #10 0x003f7cc9 in start_thread (arg=0xb207bb70) at pthread_create.c:304 #11 0x06f6a73e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 4 (Thread 0xb187ab70 (LWP 24341)): #0 0x003f1416 in __kernel_vsyscall () #1 0x06f5be76 in *__GI___poll (fds=0x6ff3ff4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x07affc0b in g_poll () from /lib/libglib-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- #3 0x07af25bc in ?? () from /lib/libglib-2.0.so.0 #4 0x07af29c8 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #5 0x0479eea5 in QEventDispatcherGlib::processEvents (this=0x9bc73f8, flags=...) at kernel/qeventdispatcher_glib.cpp:412 #6 0x0476ef29 in QEventLoop::processEvents (this=0xb187a2c0, flags=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at kernel/qeventloop.cpp:149 #7 0x0476f3aa in QEventLoop::exec (this=0xb187a2c0, flags=...) at kernel/qeventloop.cpp:201 #8 0x0466ba9e in QThread::exec (this=0x9bb62a0) at thread/qthread.cpp:490 #9 0x0466ed19 in QThreadPrivate::start (arg=0x9bb62a0) at thread/qthread_unix.cpp:266 #10 0x003f7cc9 in start_thread (arg=0xb187ab70) at pthread_create.c:304 #11 0x06f6a73e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Thread 3 (Thread 0xaa513b70 (LWP 24342)): #0 0x003f1416 in __kernel_vsyscall () #1 0x003fc864 in pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_timedwait.S:236 #2 0x075b6a2f in ?? () from /usr/lib/libxine.so.1 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 2 (Thread 0xa9106b70 (LWP 24344)): #0 0x003f1416 in __kernel_vsyscall () #1 0x06f5be76 in *__GI___poll (fds=0x6ff3ff4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x07affc0b in g_poll () from /lib/libglib-2.0.so.0 #3 0x07af25bc in ?? () from /lib/libglib-2.0.so.0 #4 0x07af29c8 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #5 0x0479eea5 in QEventDispatcherGlib::processEvents (this=0xa6a24e8, flags=...) at kernel/qeventdispatcher_glib.cpp:412 #6 0x0476ef29 in QEventLoop::processEvents (this=0xa9106250, flags=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at kernel/qeventloop.cpp:149 #7 0x0476f3aa in QEventLoop::exec (this=0xa9106250, flags=...) at kernel/qeventloop.cpp:201 #8 0x0466ba9e in QThread::exec (this=0xaaaff78) at thread/qthread.cpp:490 #9 0x097ca81a in ?? () from /usr/lib/qt4/plugins/phonon_backend/phonon_xine.so #10 0x0466ed19 in QThreadPrivate::start (arg=0xaaaff78) at thread/qthread_unix.cpp:266 #11 0x003f7cc9 in start_thread (arg=0xa9106b70) at pthread_create.c:304 #12 0x06f6a73e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 ---Type <return> to continue, or q <return> to quit--- Thread 1 (Thread 0xb663d740 (LWP 24329)): #0 0x003f1416 in __kernel_vsyscall () #1 0x06f5be76 in *__GI___poll (fds=0x6ff3ff4, nfds=21, timeout=996) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x07affc0b in g_poll () from /lib/libglib-2.0.so.0 #3 0x07af25bc in ?? () from /lib/libglib-2.0.so.0 #4 0x07af29c8 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #5 0x0479eea5 in QEventDispatcherGlib::processEvents (this=0x9a8b698, flags=...) at kernel/qeventdispatcher_glib.cpp:412 #6 0x014680e5 in QGuiEventDispatcherGlib::processEvents (this=0x9a8b698, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #7 0x0476ef29 in QEventLoop::processEvents (this=0xbfb40174, flags=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at kernel/qeventloop.cpp:149 #8 0x0476f3aa in QEventLoop::exec (this=0xbfb40174, flags=...) at kernel/qeventloop.cpp:201 #9 0x0477392f in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1009 #10 0x013a5857 in QApplication::exec () at kernel/qapplication.cpp:3665 #11 0x083bdeab in main (argc=1, argv=0xbfb406f4) at /build/buildd/digikam-1.3.0/digikam/main.cpp:195 (gdb)
Marcel, this looks like something for you ;)
You're using KDE 4.5. I'm using svn trunk and Martin is using a 4.5 packages. We get this same problem.
*** Bug 247469 has been marked as a duplicate of this bug. ***
i have same pb with konsole and ksysguard
Is there a special bug report for KDE 4.5 that summarizes this problem?
don't know if there is a special report about 4.5 but it's a long last pb since 4.2.98 ! (konsole,digikam, ksysguard)
Ok, your konsole issues etc. probably are unrelated to this bug.
digikam has also this pb since kde 4.3
is it normal digikam nepomuk service is active even if digikam is closed ?
I don't think this could have anything to do with nepomuk or digiKam's nepomuk interface, I've tried this with both nepomuk running and not running, and with the digikam nepomuk interface both on and off. Problem persists. I'm inclined to think that this is caused by the KDE 4.5 libs, probably. Because I didn't see this problem on my stable 4.4 install.
*** Bug 247550 has been marked as a duplicate of this bug. ***
I just found these lines in the kile code: // BUG 220343: Under some circumstances (Qt 4.5.3 or KDE 4.3 issues (?)) Kile doesn't terminate when the // main window is closed. So, we force this here. Everything seems to work fine with Qt 4.6. connect(m_mainWindow, SIGNAL(destroyed(QObject*)), kapp, SLOT(quit())); Can someone with this problem test if this helps?
Adding it to digikamapp.cpp indeed does solve this issue. although sometimes some errorneous behaviour then appears on the console in form of "Object::disconnect: Unexpected null parameter", but nothing serious. Works for me.
Adding QObject::connect(digikam, SIGNAL(destroyed(QObject*)), &app, SLOT(quit())); to main.cpp exits digikam on close here. I can also write: app.setQuitOnLastWindowClosed(true); and digikam exits well. The weird thing is here that according to Qt documentation, quitOnLastWindowClosed defaults to true... Anyway, thanks for looking into this! Michael
By 'also', I mean 'instead' ;-) Michael
The latter version looks much better. Maybe the flag is changed in the 4.5 version of KXmlGuiWindow? We should add that line. I don't think it will hurt. ;)
app.setQuitOnLastWindowClosed(true); does not close digikam when I close the main window while the editor is still open, though. But the connect statement closes it in this case. Michael
No problem here with KDE 4.5, never at all. If this can be traced to the switch from KDE4.4 to KDE4.5, then it is not our fault, and we should not try to add any sort of workaround to our app. It must then be fixed upstream. So from the posts above, it seems to be an issue appearing only after installing 4.5? > is it normal digikam nepomuk service is active even if digikam is closed ? Yes. it is supposed to monitor changes applied through nepomuk (rating in dolphin etc.) and feed them into digikam's db.
(In reply to comment #22) > So from the posts above, it seems to be an issue appearing only after > installing 4.5? Not sure, but for me the issue seems to be resolved for now. I think the problem is related to live system upgrade. Even though I un-logged and then relogged, I still had the problem. But after a reboot (due to the last kernel fix upgrade), digikam seems to behave correctly.
I just updated my KDE trunk sources today, and this issue is now with dolphin and konversation too. Definitely a KDE issue.
I'm having this problem of the digiKam process staying in memory every time I exit digiKam. This is with digiKam 1.4.0 running on PCLinuxOS 2010.7 and Kubuntu 10.10(beta). Both distros are running KDE 4.5.1
updated to 1.4.0, but the problem still exists
The problem appears with qt-4.7. No problem with qt-4.6.3.
(In reply to comment #27) > The problem appears with qt-4.7. No problem with qt-4.6.3. i don't agree as i said this is a long last pb if i remember since i test mandriva 2009.0 and kde 4.1 i only met this pb with konsole,ksysguard and digikam, not other app
In my case the relation between digikam and qt-4.7 is obvious. I have checked it with following: FC13 -> QT-4.6.3 -> KDE-4.4.5 -> no problem with digikam FC13 -> QT-4.6.3 -> KDE-4.5.1 -> no problem with digikam FC13 -> QT-4.7.0 -> KDE-4.4.5(recompiled against QT-4.6.3) -> the problem exists (digikam, kio_digikamalbu, kio_digikamdate remain in memory) FC13 -> QT-4.7.0 -> KDE-4.5.1(recompiled against QT-4.7.0) -> the problem exists (digikam, kio_digikamalbu, kio_digikamdate remain in memory)
*** Bug 252443 has been marked as a duplicate of this bug. ***
*** Bug 253824 has been marked as a duplicate of this bug. ***
Just for information, can you reproduce this problem with showfoto ? Gilles Caulier
No, showFoto works fine, only digiKam is not closing... need to kill it manually.
Although there are reports about other KDE apps not closing properly, I'd add the connection suggested by Johannes in #16. If it is indeed kde-libs related, then it's true, that it's not digiKam's responsibility. But anyway, adding this one line won't hurt and this bug would be solved. Well at least for digiKam :)
Moreover, almost noone experiences this problem with other applications except digiKam. So, it's better to add the suggested line to the code.
i use mandriva 2010.1 kde 4.4.3 since i updated to kde 4.5.0 (i use today kde 4.5.2) i no more have pb with konsole and ksysguard i still have pb with digikam which does not close completely.
The same problem in pre-release of Fedora 14 (digikam, kio_digikamalbu, kio_digikamdate remain in memory after closing of main window).
(In reply to comment #37) > The same problem in pre-release of Fedora 14 (digikam, kio_digikamalbu, > kio_digikamdate remain in memory after closing of main window). since kde 4.5.2 (mandriva 2010.1 32 bits) i have no more kio_digikamalbu,kio_digikamdate remaining in memory after some minutes only digikam remains in memory
Same problem here on Ubuntu 10.10 and digikam 1.4.0 :/
Created attachment 52985 [details] output of gdb thread apply all bt digikam 1.5.0 also remains in memory after quit, running under KDE 4.5.2, openSuSE 11.3 x86_64. Please see attached backtrace.
Happens on Arch Linux with KDE 4.5.2 and Qt 4.7.0 too. I had the similar problem with krusader: https://sourceforge.net/tracker/?func=detail&atid=106488&aid=3015094&group_id=6488. For me it was fixed by http://websvn.kde.org/trunk/extragear/utils/krusader/krusader/panelmanager.cpp?r1=1154581&r2=1154580&pathrev=1154581 I hope it helps.
*** This bug has been confirmed by popular vote. ***
Seeing the same behavior in up to date Kubuntu 10.10.
SVN commit 1193865 by aclemens: Add a connection to the destroyed() signal when the digiKam mainwindow has been closed. This should prevent digiKam from staying open in the background. This bug appeared for me the first time when I installed Qt4.7. Even if this is not digiKam's fault, we should make sure that the application gets closed properly. I will not close this bug until we found a better solution. CCBUG:247175 M +1 -0 main.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1193865
What should we do with this report? At least the issue is fixed now, but is this really the best / or even the right solution?
I agree. it's fixed. Under my MacBook, with Qt 4.7 + KDE 4.5.3, i cannot reproduce the problem. I propose to comment source code about this problem where you have patched implementation, and to close this file, excepted if you have other way to investiguate. Gilles Caulier
SVN commit 1198410 by aclemens: update BUG:247175 M +2 -2 NEWS M +7 -0 digikam/main.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1198410
I can confirm, this patch to main.cpp fixes the problem in Fedora 14.