Bug 247175 - digiKam doesn't exit after closing main window
Summary: digiKam doesn't exit after closing main window
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Engine (show other bugs)
Version: 1.3.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-09 22:50 UTC by Evgeny Brazgin
Modified: 2017-07-24 09:04 UTC (History)
12 users (show)

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


Attachments
output of gdb thread apply all bt (4.72 KB, application/octet-stream)
2010-10-30 10:21 UTC, Egbert König
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Evgeny Brazgin 2010-08-09 22:50:31 UTC
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
Comment 1 Johannes Wienke 2010-08-09 23:19:52 UTC
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.
Comment 2 Evgeny Brazgin 2010-08-09 23:49:06 UTC
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---
Comment 3 Johannes Wienke 2010-08-09 23:51:06 UTC
Please press enter until there is no more output ;)
Comment 4 Evgeny Brazgin 2010-08-09 23:58:04 UTC
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)
Comment 5 Johannes Wienke 2010-08-10 00:03:30 UTC
Marcel, this looks like something for you ;)
Comment 6 Aditya Bhatt 2010-08-10 00:05:12 UTC
You're using KDE 4.5.

I'm using svn trunk and Martin is using a 4.5 packages. We get this same
problem.
Comment 7 Johannes Wienke 2010-08-12 09:43:51 UTC
*** Bug 247469 has been marked as a duplicate of this bug. ***
Comment 8 Philippe ROUBACH 2010-08-12 10:00:51 UTC
i have same pb with konsole and ksysguard
Comment 9 Johannes Wienke 2010-08-12 10:11:11 UTC
Is there a special bug report for KDE 4.5 that summarizes this problem?
Comment 10 Philippe ROUBACH 2010-08-12 11:35:32 UTC
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)
Comment 11 Johannes Wienke 2010-08-12 11:53:32 UTC
Ok, your konsole issues etc. probably are unrelated to this bug.
Comment 12 Philippe ROUBACH 2010-08-12 12:08:13 UTC
digikam has also this pb since kde 4.3
Comment 13 Philippe ROUBACH 2010-08-12 19:15:40 UTC
is it normal digikam nepomuk service is active even if digikam is closed ?
Comment 14 Aditya Bhatt 2010-08-12 19:41:12 UTC
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.
Comment 15 tnemeth 2010-08-13 18:02:05 UTC
*** Bug 247550 has been marked as a duplicate of this bug. ***
Comment 16 Johannes Wienke 2010-08-13 21:27:30 UTC
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?
Comment 17 Martin Klapetek 2010-08-13 23:44:20 UTC
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.
Comment 18 Michael G. Hansen 2010-08-14 00:30:01 UTC
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
Comment 19 Michael G. Hansen 2010-08-14 00:30:37 UTC
By 'also', I mean 'instead' ;-)

Michael
Comment 20 Johannes Wienke 2010-08-14 00:37:25 UTC
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. ;)
Comment 21 Michael G. Hansen 2010-08-14 14:03:39 UTC
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
Comment 22 Marcel Wiesweg 2010-08-21 15:47:17 UTC
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.
Comment 23 tnemeth 2010-08-25 08:56:05 UTC
(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.
Comment 24 Aditya Bhatt 2010-08-25 09:02:19 UTC
I just updated my KDE trunk sources today, and this issue is now with
dolphin and konversation too. Definitely a KDE issue.
Comment 25 Martin Foster 2010-09-09 14:37:18 UTC
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
Comment 26 Evgeny Brazgin 2010-09-09 16:19:03 UTC
updated to 1.4.0, but the problem still exists
Comment 27 Alexander Malashenko 2010-09-26 00:14:52 UTC
The problem appears with qt-4.7. No problem with qt-4.6.3.
Comment 28 Philippe ROUBACH 2010-09-26 11:30:23 UTC
(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
Comment 29 Alexander Malashenko 2010-09-26 18:06:15 UTC
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)
Comment 30 caulier.gilles 2010-09-26 19:23:37 UTC
*** Bug 252443 has been marked as a duplicate of this bug. ***
Comment 31 caulier.gilles 2010-10-11 13:10:49 UTC
*** Bug 253824 has been marked as a duplicate of this bug. ***
Comment 32 caulier.gilles 2010-10-11 20:05:31 UTC
Just for information, can you reproduce this problem with showfoto ?

Gilles Caulier
Comment 33 Andi Clemens 2010-10-11 20:12:09 UTC
No, showFoto works fine, only digiKam is not closing... need to kill it manually.
Comment 34 Martin Klapetek 2010-10-11 21:47:29 UTC
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 :)
Comment 35 Evgeny Brazgin 2010-10-11 21:54:36 UTC
Moreover, almost noone experiences this problem with other applications except digiKam.
So, it's better to add the suggested line to the code.
Comment 36 Philippe ROUBACH 2010-10-11 22:15:13 UTC
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.
Comment 37 Alexander Malashenko 2010-10-23 22:33:14 UTC
The same problem in pre-release of Fedora 14 (digikam, kio_digikamalbu, kio_digikamdate remain in memory after closing of main window).
Comment 38 Philippe ROUBACH 2010-10-24 13:35:54 UTC
(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
Comment 39 Christian Weiske 2010-10-24 18:48:23 UTC
Same problem here on Ubuntu 10.10 and digikam 1.4.0 :/
Comment 40 Egbert König 2010-10-30 10:21:27 UTC
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.
Comment 41 Lukas Jirkovsky 2010-10-30 11:47:07 UTC
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.
Comment 42 Lukas Jirkovsky 2010-10-30 11:48:18 UTC
*** This bug has been confirmed by popular vote. ***
Comment 43 Logan Dethrow 2010-11-02 22:23:08 UTC
Seeing the same behavior in up to date Kubuntu 10.10.
Comment 44 Andi Clemens 2010-11-07 13:27:42 UTC
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
Comment 45 Andi Clemens 2010-11-18 01:31:45 UTC
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?
Comment 46 caulier.gilles 2010-11-18 08:29:19 UTC
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
Comment 47 Andi Clemens 2010-11-18 11:25:36 UTC
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
Comment 48 Alexander Malashenko 2010-11-19 23:45:58 UTC
I can confirm, this patch to main.cpp fixes the problem in Fedora 14.