Version: 0.9.5 (using KDE Devel) I tried to delete a file while my box was under heavy load. The deletion process hung for a minute or so, so I decided to cancel it. Pressing the Cancel button made dolphin crash with the following backtrace. I hope it is helpful... Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 0xb62c46c0 (LWP 11689)] [New Thread 0xb4a27b90 (LWP 11690)] [KCrash handler] #6 0x00034117 in ?? () #7 0xb7d143d0 in KJob::kill (this=0x84c1368, verbosity=KJob::EmitResult) at /root/kde/src/KDE/libs/kdecore/jobs/kjob.cpp:106 #8 0xb7aca9b8 in KAbstractWidgetJobTracker::slotStop (this=0x821a2d0, job=0x84c1368) at /root/kde/src/KDE/libs/kdeui/jobs/kabstractwidgetjobtracker.cpp:134 #9 0xb7acbbf2 in KWidgetJobTracker::Private::ProgressWidget::_k_stop ( this=0x84dc260) at /root/kde/src/KDE/libs/kdeui/jobs/kwidgetjobtracker.cpp:588 #10 0xb7acbf51 in KWidgetJobTracker::Private::ProgressWidget::qt_metacall ( this=0x84dc260, _c=QMetaObject::InvokeMetaMethod, _id=13, _a=0xbfe67d7c) at /root/kde/build/KDE/libs/kdeui/kwidgetjobtracker_p.moc:100 #11 0xb7f40f0a in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #12 0xb7f41250 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #13 0xb721e211 in QAbstractButton::clicked () from /usr/lib/libQtGui.so.4 #14 0xb6fe7a19 in ?? () from /usr/lib/libQtGui.so.4 #15 0x084ce5d8 in ?? () #16 0x00000000 in ?? () #0 0xffffe410 in __kernel_vsyscall ()
In the last few days I experienced this problem a lot since I clean up some collections of files (it's hard to work with folders containing thousands of files, btw). Anyway. The non-disappearing deletion dialog (that thing which should only be there for a blink of an eye on normal file deletion) and the following crash on Cancel are not limited to Dolphin. I have the same problem in Gwenview and when dragging a url from Firefox to the Konsole part embedded in Yakuake. I can continue working if I do not cancel or close the dialog but just ignore it. In one hour of cleaning out files, there is a collection of 30 to 50 open dialogs though, so I crash it from time to time to free ressources. ;) Long story short. I think this report has to be reassigned to some kio or libs folks. But what would I know. :) cheers
> Long story short. I think this report has to be reassigned > to some kio or libs folks. But what would I know. :) Thanks Frederik for the update. I agree that this is most probably an issue outside the scope of Dolphin (kdelibs or libkonq), just to be sure: with which version did you do your latest tests? KDE 4.0.0, 4.0.1 or trunk? Thanks!
I have the Debian packages of KDE 4.0.1 installed.
Erm, little mistake here. There are not all 4.0.4 packages available yet. I'll report the next days how it works if all packages are there.
4.0.1 that is. *sighs*
Added David Faure to CC for information. I'll try to reproduce this issue ASAP and hope I'm able to fix it ;-)
Were you able to reproduce it? Running 4.0.1 (this time for real :)) it feels like it has gotten worse. From 100 deletion actions I have about 20-30 dialogs hanging around.
> Were you able to reproduce it? No sorry, everything works well here... Just some questions to be sure that I do the same as you: - Do you talk from the "Delete" operation, not the "Move to Trash" operation? - Are the operations done on your local filesystem? - Does the crash only occur if the deletion process "hangs"? Do rephrase it with different words: If you press "cancel" on a deletion process which seems to work no crash occurs. Is this correct?
Ok, here is the way I can reproduce it in less than two minutes: I have a directory shown in "Icon" view with about 20.000 pictures in it. Now I press the "Preview" toolbar button. While the preview images are being loaded, I start browsing and delete some of the images already shown. It is not importent whether I "Delete" them or "Move [them] to Trash". In one of about 20 deletion actions (sometimes up to every second one) the "Progress Dialog" appears. It is the dialog that usually appears when I delete a bunch of files which takes a few seconds or longer. Here it just appears and is not "progressing" and not closing again. If I now push the "Cancel" button in this dialog, the application that called the dialog crashes. This happened to me in Dolphin, Gwenview and when I dragged a URL from Firefox to Konsole (embedded in Yakuake).
OK, I've now a folder with 20000 pictures too :-) I could reproduce the crash with KDE 4.0.0, but not with the trunk version anymore. As I don't know which bugfix solved this issue, I'm not sure whether the fix has been backported for KDE 4.0.2 too. I'd kindly ask if you could verify this issue again after KDE 4.0.2 is out? Thanks!
This sounds like kdeui jobtracker crashes, which have indeed been fixed in branch and trunk.
*** Bug has been marked as fixed ***.
On 12 Feb 2008 18:49:52 -0000, Peter Penz <peter.penz@gmx.at> wrote: > OK, I've now a folder with 20000 pictures too :-) Yay. :D > I'd kindly ask if you could verify this issue again after KDE 4.0.2 is out? Sure, I'll have a look at it. Thanks for all the work.
I seem to have the same problem, the same symptoms anyway (as in comment #9), but the difference is that the hang/crash can occur when just deleting a single file or directory. Should I open a new bugreport, or is it related to this one so it should be reopened? Trying to recreate the problem I created a couple of testfiles which I then deleted (moved to trash) one after the other until dolphin hung and crashed. This I repeated a couple of times; sometimes I could delete 10 files, but most of the time I could only delete about 3-5 files before the hang/crash. Using: Dolphin Version: 1.0.2 (KDE 4.0.2 (KDE 4.0.2), Kubuntu packages) Operating System: Linux (i686) release 2.6.22-14-generic
Well, I knew I forgot about something. :D The issue is still valid here in 4.0.2 and yes, it also happens when deleting one single file. It doesn't hang here though. Dolphin can be used as usual when the deletion dialogs stop diappearing.
I'm sorry I was unclear. I mean that the progress dialog hangs, not dolphin.
Ok, then it seems to be the same problem and you do not need too file another bug for that. I reopen this one instead. Is that ok with you Peter?
yes, i experience the same problem, not dolphin, but the progress dialog hangs also when my box is not so busy. I can provocate moving to the trash one file after another. On the third or fourth file the trash-moving dialog hangs, I cancel it and dolphin crashes with sigsegv 11. My KDE is 4.0.3, Dolphin is 1.0.2, compiler gcc, ditribution Suse 10.3
Now I have also experienced the same behaviour in Gwenview, as in comment #1. Although I can't delete files from Gwenview, the problem occurs when viewing images in an archive. So my guess is that Gwenview tries to delete a temporary file, thus ending up with the same kind of progress dialog as described above, which crashes Gwenview if cancelled. Did a quick search and found this bug which looks related: http://bugs.kde.org/show_bug.cgi?id=156554
I experienced the same bug when I was copying files to my USB Drive. I DnD'ed two files in a row and the process dialog box hang and when I pressed cancel, dolphin crashed. Should I create a separate bug report for this?? I have compiled KDE from SVN today gcc (openSUSE Linux 11.0 RC1) 4.3.1 20080507. The bugtrace follows: Application: Dolphin (dolphin), signal SIGSEGV [?1034h[Thread debugging using libthread_db enabled] [New Thread 0x7f3eb2d4b700 (LWP 6171)] [KCrash handler] #5 0x0000002100000040 in ?? () #6 0x00007f3eb10a3173 in KJob::kill (this=0x9e6bb0, verbosity=KJob::EmitResult) at /home/khare/kde/src/trunk/KDE/kdelibs/kdecore/jobs/kjob.cpp:106 #7 0x00007f3eb1de2c98 in KAbstractWidgetJobTracker::slotStop (this=0x11f9310, job=0x9e6bb0) at /home/khare/kde/src/trunk/KDE/kdelibs/kdeui/jobs/kabstractwidgetjobtracker.cpp:129 #8 0x00007f3eb1de39ed in KWidgetJobTracker::Private::ProgressWidget::_k_stop ( this=0xb4a890) at /home/khare/kde/src/trunk/KDE/kdelibs/kdeui/jobs/kwidgetjobtracker.cpp:595 #9 0x00007f3eb1de418d in KWidgetJobTracker::Private::ProgressWidget::qt_metacall (this=0xb4a890, _c=QMetaObject::InvokeMetaMethod, _id=13, _a=0x7fffbad83a20) at /home/khare/kde/build/trunk/KDE/kdelibs/kdeui/kwidgetjobtracker_p.moc:101 #10 0x00007f3eb0a6c4e0 in QMetaObject::activate () from /usr/lib64/libQtCore.so.4 #11 0x00007f3eadcf8847 in QAbstractButton::clicked () from /usr/lib64/libQtGui.so.4 #12 0x00007f3eadab9cdb in ?? () from /usr/lib64/libQtGui.so.4 #13 0x00007f3eadabaa32 in ?? () from /usr/lib64/libQtGui.so.4 #14 0x00007f3eadabac65 in QAbstractButton::mouseReleaseEvent () from /usr/lib64/libQtGui.so.4 #15 0x00007f3ead845484 in QWidget::event () from /usr/lib64/libQtGui.so.4 #16 0x00007f3ead7f892d in QApplicationPrivate::notify_helper () from /usr/lib64/libQtGui.so.4 #17 0x00007f3ead7ff566 in QApplication::notify () from /usr/lib64/libQtGui.so.4 #18 0x00007f3eb1deff4a in KApplication::notify (this=0x7fffbad84e90, receiver=0xb564b0, event=0x7fffbad84200) at /home/khare/kde/src/trunk/KDE/kdelibs/kdeui/kernel/kapplication.cpp:311 #19 0x00007f3eb0a5ae9c in QCoreApplication::notifyInternal () from /usr/lib64/libQtCore.so.4 #20 0x00007f3ead800838 in QApplicationPrivate::sendMouseEvent () from /usr/lib64/libQtGui.so.4 #21 0x00007f3ead8568dc in ?? () from /usr/lib64/libQtGui.so.4 #22 0x00007f3ead8554fb in QApplication::x11ProcessEvent () from /usr/lib64/libQtGui.so.4 #23 0x00007f3ead87959c in ?? () from /usr/lib64/libQtGui.so.4 #24 0x00007f3eb0a597f2 in QEventLoop::processEvents () from /usr/lib64/libQtCore.so.4 #25 0x00007f3eb0a59985 in QEventLoop::exec () from /usr/lib64/libQtCore.so.4 #26 0x00007f3eb0a5ba25 in QCoreApplication::exec () from /usr/lib64/libQtCore.so.4 #27 0x0000000000442507 in main (argc=6, argv=0x7fffbad85358) at /home/khare/kde/src/trunk/KDE/kdebase/apps/dolphin/src/main.cpp:94 #0 0x00007f3eab87c230 in nanosleep () from /lib64/libc.so.6
I've reassigned this issue to kdelibs.
Please retry again (updating kdelibs). I committed early today a patch that may fix this crash.
*** Bug 159206 has been marked as a duplicate of this bug. ***
*** Bug 163537 has been marked as a duplicate of this bug. ***
Any news here ? Closing as FIXED. Please if you experience this problem again, reopen the bug.
Using 4.0.5 (Fedora 9) here. I also sometimes experience stalled deletes (moves to trash). When I meanwhile go to trash and try to empty it (the things that are in there), I get a popup from one of the stalled images that the trash-process died unexpectedly. When I don't do anything the deletes seem to be hanging around "forever". This was experienced using a USB-HDD. Not sure if a fixed drive results in the same problem.
This has been fixed for 4.1.0.
Hi, I just experienced this bug again with r827515 (about a day old). I deleted a video file 200 MB in size. The dialog didn't disappear, Pressing Cancel leads to a crash of the application that calles the dialog. Regards
Frederik, did you update kdelibs ? I am pretty sure the fix I wrote was correct, and I cannot reproduce it here.
Yes, I updated everything yesterday to the revision I said. The error does not occour every time. It happens only once in about 50 deletion actions. It is hard to reproduce here either but it just happens once in a while.
Is the crash backtrace the same ? I would be interested in the backtrace since I can't reproduce.
Yes, here is the Backtrace. Again some hints on how I managed to reproduce it pretty fast. - Compile something in background so the responce time increases. - Create files e.g. with "for i in $(seq 100); do touch $i.txt; done" - Delete them fast with Shift Del and Enter; select the next file then with arrow keys Anyway, here's the backtrace: Application: Dolphin (dolphin), Signal SIGSEGV [Thread debugging using libthread_db enabled] [New Thread 0xb5f03720 (LWP 28432)] [KCrash handler] #6 0x0000002a in ?? () #7 0xb7754cf2 in KJob::kill (this=0x838b538, verbosity=KJob::EmitResult) at /home/compiler/kde/src/KDE/libs/kdecore/jobs/kjob.cpp:106 #8 0xb7ba7666 in KAbstractWidgetJobTracker::slotStop (this=0x83f4498, job=0x838b538) at /home/compiler/kde/src/KDE/libs/kdeui/jobs/kabstractwidgetjobtracker.cpp:129 #9 0xb7ba8224 in KWidgetJobTracker::Private::ProgressWidget::_k_stop ( this=0x83fa7b8) at /home/compiler/kde/src/KDE/libs/kdeui/jobs/kwidgetjobtracker.cpp:629 #10 0xb7ba8a9b in KWidgetJobTracker::Private::ProgressWidget::qt_metacall ( this=0x83fa7b8, _c=QMetaObject::InvokeMetaMethod, _id=13, _a=0xbfbf724c) at /home/compiler/kde/build/KDE/libs/kdeui/kwidgetjobtracker_p.moc:101 #11 0xb7557090 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #12 0xb7557490 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #13 0xb6df5da1 in QAbstractButton::clicked () from /usr/lib/libQtGui.so.4 #14 0xb6b4b789 in ?? () from /usr/lib/libQtGui.so.4 #15 0xb6b4d2f4 in ?? () from /usr/lib/libQtGui.so.4 #16 0xb6b4d586 in QAbstractButton::mouseReleaseEvent () from /usr/lib/libQtGui.so.4 #17 0xb686c4f2 in QWidget::event () from /usr/lib/libQtGui.so.4 #18 0xb6b4b62e in QAbstractButton::event () from /usr/lib/libQtGui.so.4 #19 0xb6bf1570 in QPushButton::event () from /usr/lib/libQtGui.so.4 #20 0xb681466c in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #21 0xb681cdf1 in QApplication::notify () from /usr/lib/libQtGui.so.4 #22 0xb7bb54e1 in KApplication::notify (this=0xbfbf80ac, receiver=0x83e0a20, event=0xbfbf78ec) at /home/compiler/kde/src/KDE/libs/kdeui/kernel/kapplication.cpp:311 #23 0xb7542541 in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #24 0xb681c07e in QApplicationPrivate::sendMouseEvent () from /usr/lib/libQtGui.so.4 #25 0xb68855fd in ?? () from /usr/lib/libQtGui.so.4 #26 0xb68843cf in QApplication::x11ProcessEvent () from /usr/lib/libQtGui.so.4 #27 0xb68add14 in ?? () from /usr/lib/libQtGui.so.4 #28 0xb613a278 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #29 0xb613d913 in ?? () from /usr/lib/libglib-2.0.so.0 #30 0x080b6638 in ?? () #31 0x00000000 in ?? () #0 0xb7fdc424 in __kernel_vsyscall ()
Thanks for the detailed explanation. Among the steps you told me to reproduce, that backtrace tells me you needed to press "Cancel" at least on one of them. Did you press "Cancel" for some of them ? one ? all of them ?
*** Bug 165716 has been marked as a duplicate of this bug. ***
Yes, sometimes the deletion dialog does not dissapear... then, if I press the Cancel button, the application that called that dialog crashes.
Can you please try to apply the attached patch on kdelibs ? The diff has been generated with git, so you probably need to apply it with "patch -p1". Created an attachment (id=25840) kdelibs-kdeui-jobs.diff
Can you please try to apply the attached patch on kdelibs ? The diff has been generated with git, so you probably need to apply it with "patch -p1". Created an attachment (id=25841) kdelibs-kdeui-jobs.diff
SVN commit 828695 by ereslibre: Fix the way the job tracker handles jobs. This implementation fixes all the previous problems and respects all flags set to the tracker (stopOnClose and autoDelete). BUG: 154925 CCMAIL: ervin@kde.org, faure@kde.org M +4 -0 kdecore/jobs/kjobtrackerinterface.cpp M +1 -0 kdecore/jobs/kjobtrackerinterface.h M +6 -15 kdeui/jobs/kabstractwidgetjobtracker.cpp M +3 -0 kdeui/jobs/kabstractwidgetjobtracker.h M +37 -42 kdeui/jobs/kwidgetjobtracker.cpp M +3 -0 kdeui/jobs/kwidgetjobtracker.h M +1 -8 kdeui/jobs/kwidgetjobtracker_p.h WebSVN link: http://websvn.kde.org/?view=rev&revision=828695
Thank you for your efforts! I will test it exhaustively. :)
http://bugs.kde.org/show_bug.cgi?id=165912 has the same backtrace. (hitting cancel on a progress dialog from kopete, after looking at a url that was sent to you) reproducible for me r828842 kdelibs (r828851 kdenetwork) So I should have this fix?
Nope, what you are reproducing is a different issue. You are hitting cancel on a 'stat' operation, what is different of this one. Technically this bug is fixed, now we have to take care of #165912
*** Bug 166157 has been marked as a duplicate of this bug. ***