Bug 253129 - Closing the ark window do not kill the ark process
Summary: Closing the ark window do not kill the ark process
Status: RESOLVED DUPLICATE of bug 193908
Alias: None
Product: ark
Classification: Applications
Component: general (show other bugs)
Version: 2.15
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Harald Hvaal
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-03 16:01 UTC by Dmitry Samoyloff
Modified: 2010-10-23 19:32 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Samoyloff 2010-10-03 16:01:48 UTC
Version:           2.15 (using KDE 4.5.1) 
OS:                Linux

If I open some big archive (tar.bz2) clicking it in a file manager and close the Ark window while it still extracting the files, the window closes but the ark process persists, I can see it using "top" and it still unpacking the stuff.

Sometimes Ark even crashes at quitting (yes, I know about the old-time Bug 193908, but I don't know how much these bugs are related to each other).

(I've chose "Happen every time" because it always either remains working or crashes.)


Reproducible: Always

Steps to Reproduce:
1. Open a huge archive.
2. Close the Ark window while unpacking.


Actual Results:  
The Ark's process is still working in background (or Ark segfaults).


Expected Results:  
Ark's process should be terminated successfully.
Comment 1 Raphael Kubo da Costa 2010-10-16 06:00:11 UTC
I think it should crash or stay in the background forever depending on the file format. Can you recognize any pattern here, and, more importantly, what backtrace do you get when it crashes?
Comment 2 Dmitry Samoyloff 2010-10-23 19:22:20 UTC
I've tried .tar.bz2 and it either stayed in background, or crashed ark, so it seems random to me. That was in KDE-4.5.1.

Since I've installed KDE-4.5.2 (the Ark version is still 2.15), this "backgrounding" may only be reproduced by closing the window instantly after it emerged, but anyways it leads to a crash very soon (after several seconds).

Here's the backtrace, it looks pretty much the same as in bug 193908 :

Application: Ark (ark), signal: Segmentation fault
[Current thread is 1 (Thread 0x7f5db14a4760 (LWP 24518))]

Thread 2 (Thread 0x7f5da06d9710 (LWP 24519)):
[KCrash Handler]
#6  0x00007f5db10a7327 in Kerfuffle::ReadOnlyArchiveInterface::entry(QHash<int, QVariant> const&) () from /usr/lib/libkerfuffle.so.4
#7  0x00007f5da0ee4b0e in ?? () from /usr/lib64/kde4/kerfuffle_libarchive.so
#8  0x00007f5da0ee6f00 in ?? () from /usr/lib64/kde4/kerfuffle_libarchive.so
#9  0x00007f5db10a857f in Kerfuffle::ListJob::doWork() () from /usr/lib/libkerfuffle.so.4
#10 0x00007f5db10a83bd in Kerfuffle::ListJob::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libkerfuffle.so.4
#11 0x00007f5daebd5198 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib64/qt4/libQtCore.so.4
#12 0x00007f5daebd1883 in QObject::event(QEvent*) () from /usr/lib64/qt4/libQtCore.so.4
#13 0x00007f5daf57098d in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#14 0x00007f5daf577da4 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#15 0x00007f5db0297d76 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#16 0x00007f5daebc198c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/qt4/libQtCore.so.4
#17 0x00007f5daebeeff4 in ?? () from /usr/lib64/qt4/libQtCore.so.4
#18 0x00007f5daebeb694 in ?? () from /usr/lib64/qt4/libQtCore.so.4
#19 0x00007f5dab0bd160 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#20 0x00007f5dab0c0fb8 in ?? () from /usr/lib/libglib-2.0.so.0
#21 0x00007f5dab0c116c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#22 0x00007f5daebeb39c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#23 0x00007f5daebc0272 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#24 0x00007f5daebc0644 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#25 0x00007f5daeaceb79 in QThread::exec() () from /usr/lib64/qt4/libQtCore.so.4
#26 0x00007f5db10aa27a in ?? () from /usr/lib/libkerfuffle.so.4
#27 0x00007f5daead1375 in ?? () from /usr/lib64/qt4/libQtCore.so.4
#28 0x00007f5dac6764f7 in start_thread () from /lib/libpthread.so.0
#29 0x00007f5dae4bb28d in clone () from /lib/libc.so.6

Thread 1 (Thread 0x7f5db14a4760 (LWP 24518)):
#0  0x00007f5dac67a3ec in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x00007f5daead22e9 in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/qt4/libQtCore.so.4
#2  0x00007f5daead1424 in QThread::wait(unsigned long) () from /usr/lib64/qt4/libQtCore.so.4
#3  0x00007f5db10a7c61 in Kerfuffle::Job::~Job() () from /usr/lib/libkerfuffle.so.4
#4  0x00007f5db10aa022 in ?? () from /usr/lib/libkerfuffle.so.4
#5  0x00007f5daebd03e1 in QObjectPrivate::deleteChildren() () from /usr/lib64/qt4/libQtCore.so.4
#6  0x00007f5daebd7f3d in QObject::~QObject() () from /usr/lib64/qt4/libQtCore.so.4
#7  0x00007f5db10aa81f in Kerfuffle::ArchiveBase::~ArchiveBase() () from /usr/lib/libkerfuffle.so.4
#8  0x00007f5da2838e0d in ?? () from /usr/lib64/kde4/arkpart.so
#9  0x00007f5daebd03e1 in QObjectPrivate::deleteChildren() () from /usr/lib64/qt4/libQtCore.so.4
#10 0x00007f5daebd7f3d in QObject::~QObject() () from /usr/lib64/qt4/libQtCore.so.4
#11 0x00007f5db0ba1902 in KParts::Part::~Part() () from /usr/lib/libkparts.so.4
#12 0x00007f5da282bd2b in ?? () from /usr/lib64/kde4/arkpart.so
#13 0x000000000040f41b in _start ()

I suppose this bug may be marked as duplicate of 193908 now.
Comment 3 Raphael Kubo da Costa 2010-10-23 19:32:04 UTC
Alright, thanks for the investigation!

*** This bug has been marked as a duplicate of bug 193908 ***