Bug 168691 - Dolphin crash when trying to undo a move to trash operation
Summary: Dolphin crash when trying to undo a move to trash operation
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR crash
Target Milestone: ---
Assignee: kdelibs bugs
: 168688 (view as bug list)
Depends on:
Reported: 2008-08-08 04:43 UTC by Yannick Cholette
Modified: 2008-08-13 01:39 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:

Fix the crash (2.51 KB, patch)
2008-08-09 09:47 UTC, Rafael Fernández López
Fix the crash (take 2) (5.31 KB, patch)
2008-08-10 16:33 UTC, Rafael Fernández López

Note You need to log in before you can comment on or make changes to this bug.
Description Yannick Cholette 2008-08-08 04:43:21 UTC
Version:            (using KDE 4.1.0)
Compiler:          gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.1) CFLAGS="-O2 -pipe -ggdb" CXXFLAGS="${CFLAGS}" CHOST="x86_64-pc-linux-gnu"
OS:                Linux

1. Switch to "Details" view and activate "Expandable folders".
2. Go to a dir containing other dirs.
3. Expand one of those. Select it and one of its file.
4. Move them to trash.
5. Undo the operation.

The "Moving" dialog get stuck and never finish. If you cancel the operation dolphin will crash.
Comment 1 Yannick Cholette 2008-08-08 05:18:30 UTC
Application: Dolphin (dolphin), signal SIGSEGV
Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 0x2b69e3a42060 (LWP 22495)]
[KCrash handler]
#5  0x00002b69dcc806f6 in KJob::kill ()
   from /usr/kde/4.1/lib64/libkdecore.so.5
#6  0x00002b69dc090ac1 in KAbstractWidgetJobTracker::slotStop ()
   from /usr/kde/4.1/lib64/libkdeui.so.5
#7  0x00002b69dc092bbb in ?? () from /usr/kde/4.1/lib64/libkdeui.so.5
#8  0x00002b69dc092d3a in ?? () from /usr/kde/4.1/lib64/libkdeui.so.5
#9  0x00002b69dd38690c in QMetaObject::activate ()
   from /usr/lib64/qt4/libQtCore.so.4
#10 0x00002b69e034ecf7 in QAbstractButton::clicked ()
   from /usr/lib64/qt4/libQtGui.so.4
#11 0x00002b69e00e77cb in ?? () from /usr/lib64/qt4/libQtGui.so.4
#12 0x00002b69e00e9225 in ?? () from /usr/lib64/qt4/libQtGui.so.4
#13 0x00002b69e00e945d in QAbstractButton::mouseReleaseEvent ()
   from /usr/lib64/qt4/libQtGui.so.4
#14 0x00002b69dfe3b9be in QWidget::event () from /usr/lib64/qt4/libQtGui.so.4
#15 0x00002b69e00e83af in QAbstractButton::event ()
   from /usr/lib64/qt4/libQtGui.so.4
#16 0x00002b69e017ca17 in QPushButton::event ()
   from /usr/lib64/qt4/libQtGui.so.4
#17 0x00002b69dfdebcbe in QApplicationPrivate::notify_helper ()
   from /usr/lib64/qt4/libQtGui.so.4
#18 0x00002b69dfdf0bbc in QApplication::notify ()
   from /usr/lib64/qt4/libQtGui.so.4
#19 0x00002b69dc09cc73 in KApplication::notify ()
   from /usr/kde/4.1/lib64/libkdeui.so.5
#20 0x00002b69dd3729f8 in QCoreApplication::notifyInternal ()
   from /usr/lib64/qt4/libQtCore.so.4
#21 0x00002b69dfdee611 in QApplicationPrivate::sendMouseEvent ()
   from /usr/lib64/qt4/libQtGui.so.4
#22 0x00002b69dfe4d2fd in ?? () from /usr/lib64/qt4/libQtGui.so.4
#23 0x00002b69dfe4c0a3 in QApplication::x11ProcessEvent ()
   from /usr/lib64/qt4/libQtGui.so.4
#24 0x00002b69dfe6fb75 in ?? () from /usr/lib64/qt4/libQtGui.so.4
#25 0x00002b69dd371d75 in QEventLoop::processEvents ()
   from /usr/lib64/qt4/libQtCore.so.4
#26 0x00002b69dd371ed8 in QEventLoop::exec ()
   from /usr/lib64/qt4/libQtCore.so.4
#27 0x00002b69dd373bfe in QCoreApplication::exec ()
   from /usr/lib64/qt4/libQtCore.so.4
#28 0x000000000043d2f9 in main (argc=6, argv=0x7fffcf9c2b38)
    at /var/tmp/portage/kde-base/dolphin-4.1.0/work/dolphin-4.1.0/apps/dolphin/src/main.cpp:94
#29 0x00002b69e225fb74 in __libc_start_main () from /lib64/libc.so.6
#30 0x0000000000421809 in _start ()
#0  0x00002b69e22d47b0 in nanosleep () from /lib64/libc.so.6
Comment 2 Rafael Fernández López 2008-08-08 09:07:32 UTC
Interesting. I'd like to clarify that if you _only_ select and trash the folder (not the folder AND one item inside) it will undo the operation correctly. So obviously, from the user point of view is not very useful to select the folder and "a file" in it, since ALL files in it will be trashed.

Wherever the bug is, it seems to me like it should avoid adding to the list to be trashed items that are childs of folders being trashed (since they are implicitly trashed), and probably this makes the undo operation failing somehow.

Just a rough thought from testing the issue, not backtrace/ioslave etc read yet.

The backtrace provided is not very useful (it is useful in terms that you did it allright, it is a "valid" backtrace), but it just tells us the job was finished unexpectedly, probably because of what I said.
Comment 3 Christophe Marin 2008-08-08 09:46:05 UTC
Note: also see bug 168688
Comment 4 George Kiagiadakis 2008-08-08 09:52:24 UTC
*** Bug 168427 has been marked as a duplicate of this bug. ***
Comment 5 George Kiagiadakis 2008-08-08 10:01:51 UTC
bug 168427 has different steps to reproduce, however, the bactrace is very very similar, they both are related to "undo trash" operations and they both show that endless move dialog. Please reopen if you believe it's a different bug.
Comment 6 George Kiagiadakis 2008-08-08 10:14:34 UTC
That's a better backtrace of the crash described at bug 168427

Application: Dolphin (dolphin), signal SIGSEGV
[Thread debugging using libthread_db enabled]
[New Thread 0x7feb004f2780 (LWP 12887)]
[KCrash handler]
#5  0x0000000000e96750 in ?? ()
#6  0x00007feaff14dfc9 in KJob::kill (this=0x8dabb0, 
    at /tmp/buildd/kde4libs-4.1.0/kdecore/jobs/kjob.cpp:106
#7  0x00007feaff6beb41 in KAbstractWidgetJobTracker::slotStop (
    this=0x10665a0, job=0x8dabb0)
    at /tmp/buildd/kde4libs-4.1.0/kdeui/jobs/kabstractwidgetjobtracker.cpp:80
#8  0x00007feaff6c114b in KWidgetJobTracker::Private::ProgressWidget::_k_stop
    at /tmp/buildd/kde4libs-4.1.0/kdeui/jobs/kwidgetjobtracker.cpp:642
#9  0x00007feaff6c11e0 in KWidgetJobTracker::Private::ProgressWidget::qt_metacall (this=0x1128e90, _c=QMetaObject::InvokeMetaMethod, 
    _id=<value optimized out>, _a=0x7fff08628d30)
    at /tmp/buildd/kde4libs-4.1.0/obj-x86_64-linux-gnu/kdeui/kwidgetjobtracker_p.moc:101
#10 0x00007feafdad1764 in QMetaObject::activate (sender=0x117e000, 
    from_signal_index=<value optimized out>, to_signal_index=30, 
    argv=0x7fff08628d30) at kernel/qobject.cpp:3010
#11 0x00007feafe75b6e7 in QAbstractButton::clicked (this=0x8dabb0, _t1=false)
    at .moc/release-shared/moc_qabstractbutton.cpp:185
#12 0x00007feafe4e153b in QAbstractButtonPrivate::emitClicked (this=0x10f4da0)
    at widgets/qabstractbutton.cpp:543
#13 0x00007feafe4e3082 in QAbstractButtonPrivate::click (this=0x10f4da0)
    at widgets/qabstractbutton.cpp:536
#14 0x00007feafe4e32d5 in QAbstractButton::mouseReleaseEvent (this=0x117e000, 
    e=0x7fff08629670) at widgets/qabstractbutton.cpp:1112
#15 0x00007feafe22f3af in QWidget::event (this=0x8dabb0, event=0x7fff08629670)
    at kernel/qwidget.cpp:6927
#16 0x00007feafe1dce5d in QApplicationPrivate::notify_helper (this=0x68c150, 
    receiver=0x117e000, e=0x7fff08629670) at kernel/qapplication.cpp:3772
#17 0x00007feafe1e539a in QApplication::notify (this=<value optimized out>, 
    receiver=0x117e000, e=0x7fff08629670) at kernel/qapplication.cpp:3501
#18 0x00007feaff6cabfb in KApplication::notify (this=0x7fff0862a300, 
    receiver=0x117e000, event=0x7fff08629670)
    at /tmp/buildd/kde4libs-4.1.0/kdeui/kernel/kapplication.cpp:311
#19 0x00007feafdabd411 in QCoreApplication::notifyInternal (
    this=0x7fff0862a300, receiver=0x117e000, event=0x7fff08629670)
    at kernel/qcoreapplication.cpp:587
#20 0x00007feafe1e4738 in QApplicationPrivate::sendMouseEvent (
    receiver=0x117e000, event=0x7fff08629670, alienWidget=0x117e000, 
    nativeWidget=0x1128e90, buttonDown=<value optimized out>, 
    at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:218
#21 0x00007feafe248719 in QETWidget::translateMouseEvent (this=0x1128e90, 
    event=<value optimized out>) at kernel/qapplication_x11.cpp:4133
#22 0x00007feafe2475ef in QApplication::x11ProcessEvent (this=0x40, 
    event=0x7fff08629f40) at kernel/qapplication_x11.cpp:3255
#23 0x00007feafe26e9cc in x11EventSourceDispatch (s=0x68f810, callback=0, 
    user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:148
#24 0x00007feaf9c39892 in IA__g_main_context_dispatch (context=0x68e920)
    at /build/buildd/glib2.0-2.16.4/glib/gmain.c:2012
#25 0x00007feaf9c3d01d in g_main_context_iterate (context=0x68e920, block=1, 
    dispatch=1, self=<value optimized out>)
    at /build/buildd/glib2.0-2.16.4/glib/gmain.c:2645
#26 0x00007feaf9c3d1db in IA__g_main_context_iteration (context=0x68e920, 
    may_block=1) at /build/buildd/glib2.0-2.16.4/glib/gmain.c:2708
#27 0x00007feafdae583f in QEventDispatcherGlib::processEvents (this=0x67fe50, 
    flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:325
#28 0x00007feafe26e16f in QGuiEventDispatcherGlib::processEvents (
    this=0x8dabb0, flags=<value optimized out>)
    at kernel/qguieventdispatcher_glib.cpp:204
#29 0x00007feafdabbd22 in QEventLoop::processEvents (
    this=<value optimized out>, flags={i = 140681776})
    at kernel/qeventloop.cpp:149
#30 0x00007feafdabbead in QEventLoop::exec (this=0x7fff0862a270, flags=
      {i = 140681856}) at kernel/qeventloop.cpp:200
#31 0x00007feafdabe37d in QCoreApplication::exec ()
    at kernel/qcoreapplication.cpp:845
#32 0x000000000044179d in main (argc=6, argv=0x7fff0862a7f8)
    at /tmp/buildd/kdebase-4.1.0/apps/dolphin/src/main.cpp:94
#0  0x00007feafce7d210 in __nanosleep_nocancel () from /lib/libc.so.6

Now it seems to me exactly the same as the one in comment 1 :)
However, I am not able to reproduce the bug as described here, just because the files get deleted permanently (as described in bug 168688)
Comment 7 Rafael Fernández López 2008-08-08 10:45:49 UTC
I really believe the deletion instead of trashing (bug 168688) can be actually this same bug, since take into account that you are actually doing operations that can be of high risk.

For instance, if you have:

 |- a.txt
 |- b.txt

And you select "test" and "b.txt", and click on "move to trash", internally it should discard "b.txt", but if it tries to trash it too, it can lead to inconsistencies in the case that "test" is moved to trash before b.txt is, so when it later is going to move b.txt it can't find the file.

Actually yes, the backtrace Yannick provided is incomplete since it is missing the line information (a very valuable information), but well, I can track the calls and have an idea... but... in this very special case, none of the bugreports are telling anything important, just that we know that the job has finished unexpectedly. Since the kioslave is being executed in a different process, that is what we really need to debug, not the application proccess (that is what you are getting here...).
Comment 8 Yannick Cholette 2008-08-08 15:45:46 UTC
Rafael: You are right, it doesn't make much sense to do to that, but it happened to me by accident.

I will try to recompile some packages with better debug informations to see if I could provide a more useful backtrace, but like you said it's probably more of a kio problem. In all cases, removing the child file from the list to move will probably fix the bug.
Comment 9 Rafael Fernández López 2008-08-09 09:47:46 UTC
Created attachment 26748 [details]
Fix the crash

The main problem remains at this point of how the selected urls are managed.
The operation is done for all of them, without restrictions.

An example of a wrong way would be, for instance:

In a tree of the way:

-- test (*) (folder)
 | -- a.txt
 | -- b.txt (*)

where * means the file/folder is selected. Trashing this selection could
trigger a failure if the order of the url list is "test, b.txt". Since test
will be trashed (and implicitly all subitems will also), so when b.txt will
tried to be trashed, it will fail because the system cannot find the file.

This patch what makes is to discard from the list all items that are childs of
another already selected item (that implicitly makes it selected too).
Comment 10 George Kiagiadakis 2008-08-10 10:07:12 UTC
@ereslibre: Your patch looks good and it should fix this bug and possibly bug 168688, but it doesn't fix bug 168427. The nature of your patch makes me understand that you want to fix this in the application level, not the libraries level. So, should we reopen and reassign bug 168427 to dolphin? The title should read "do not allow undo trash if trash is empty"... But I thought it was a kdelibs bug, that's why I marked it as duplicate. I am sorry if I did wrong.
Comment 11 Rafael Fernández López 2008-08-10 16:33:31 UTC
Created attachment 26768 [details]
Fix the crash (take 2)

Well, I didn't know about those bugs, but in any case I am posting a patch for
this bug report.

I have seen bug 168427 and as I said before, the backtraces here are not
relevant. It is not a duplicate of this bug, is a different issue.

However, I have improved the patch (you can read the code comments of the patch
for further information).

About reassigning bug 168427, no, it is fine on kdelibs/kio bugs, but for sure
not a duplicate, just as new.
Comment 12 Rafael Fernández López 2008-08-10 16:35:36 UTC
Oh, and btw, this is in a library, libkonq, it is not "application specific fix".
Comment 13 Peter Penz 2008-08-12 19:51:15 UTC
*** Bug 168688 has been marked as a duplicate of this bug. ***
Comment 14 Rafael Fernández López 2008-08-13 01:39:45 UTC
SVN commit 846100 by ereslibre:

Simplify the list of urls when needed (moving, trashing, deleting). I am okay with a method renaming.

BUG: 168691
BUG: 168427
CCMAIL: peter.penz@gmx.at
CCMAIL: faure@kde.org

 M  +2 -0      konq_operations.cpp  
 M  +22 -1     konqmimedata.cpp  
 M  +12 -0     konqmimedata.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=846100