Version: (using KDE KDE 3.1.94) Installed from: Compiled From Sources OS: Linux How to reproduce: * Put a file or folder (just anything) on your desktop and open one konqueror window in filebrowsing mode. Do not maximize it, both konqueror and desktop must be visible. * Grab the file on the desktop and drag it *very quickly* to the konqueror window and drop it as soon as possible. It is very important that you actually 'trow' the file at konqueror in the most uncivilized way you can :) Konqueror will crash immediately.
You can also crash KDesktop by fast-dragging a file from a konqueror window to the desktop.
It seems that if you accidentally touch a konqueror window while dragging a file icon across the desktop, the konqueror window crashes immediately. Here's how to reproduce it most easily: * Open Konqueror, either in file or web browsing mode, it doesn't matter. * Resize Konqueror so that a strip of the desktop background is visible on either side of the window. * Grab a file icon and repeatedly drag it between the left and right edge of the screen, across the window. The faster you do this, the faster Konqueror will die. The funny thing is, many times the KDE crash handler does not pop up. Konqueror just disappears.
I have the same problem! (KDE 3.2, SuSE rpms) 1. I opened a linked Folder on my Desktop 2. I dragged this linked Folder Icon from one point on the Desktop to an other! (Only "normal", not fast, not "uncivilized") 3. The Konqueror windows from the linked Folder crashed. I have the following Backtrace for this crash: [New Thread 16384 (LWP 2272)] 0x4129ea86 in waitpid () from /lib/i686/libpthread.so.0 #0 0x4129ea86 in waitpid () from /lib/i686/libpthread.so.0 #1 0x407b8a7a in KCrash::defaultCrashHandler(int) () from /opt/kde3/lib/libkdecore.so.4 #2 0x4129d96c in __pthread_sighandler () from /lib/i686/libpthread.so.0 #3 <signal handler called> #4 0x40ba25cb in QFont::QFont(QFont const&) () from /usr/lib/qt3/lib/libqt-mt.so.3 #5 0x40b45e31 in QPainter::begin(QPaintDevice const*, bool) () from /usr/lib/qt3/lib/libqt-mt.so.3 #6 0x40dbbb92 in QIconView::drawDragShapes(QPoint const&) () from /usr/lib/qt3/lib/libqt-mt.so.3 #7 0x08530618 in ?? () Really strange bug!
This crash just happened when konqueror is the only opened application on the Desktop
Same here. I don't think I was stressing the system; I merely dragged something from the desktop over to a Konqueror window opened to a local filesystem. I didn't even drop the icon; Konqueror crashed when my mouse entered the window. Backtrace is appended. (no debugging symbols found)...Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 1173)] 0x41299688 in waitpid () from /lib/libpthread.so.0 #0 0x41299688 in waitpid () from /lib/libpthread.so.0 #1 0x40802024 in ?? () from /usr/kde/3.2/lib/libkdecore.so.4 #2 0x4073df21 in KCrash::defaultCrashHandler(int) () from /usr/kde/3.2/lib/libkdecore.so.4 #3 0x41298405 in __pthread_sighandler () from /lib/libpthread.so.0 #4 <signal handler called> #5 0x40ad6d4b in QFont::QFont(QFont const&) () from /usr/qt/3/lib/libqt-mt.so.3 #6 0x40a7f532 in QPainter::begin(QPaintDevice const*, bool) () from /usr/qt/3/lib/libqt-mt.so.3 #7 0x40ce2af7 in QIconView::drawDragShapes(QPoint const&) () from /usr/qt/3/lib/libqt-mt.so.3 #8 0x0872a6b8 in ?? ()
I can reproduce it on my system with about the same stack trace - P4 1.5GHz, KDE3.2 from latest Mandrake RPMs. Notice that when you start dragging, there is a slight delay between the time the mouse starts to move to the time the drag icon and rectangle appears - if you drag fast enough, the mouse enters the konqueror window before the drag notification can be be drawn and that causes the window to crash. Although the stack trace seems to suggest that this is a Qt bug, I tried to repduce the error with other KDE apps that accept drag and drop (such as the kmail composer) and couldn't induce a crash - which may possible mean its a konqueror bug after all.
*** Bug 75444 has been marked as a duplicate of this bug. ***
*** Bug 75788 has been marked as a duplicate of this bug. ***
Two konqueror windows and the desktop just crashed with one drag. This time the window I was dragging FROM also crashed. I've witnessed this bug constantly in KDE 3.2.1 built from gentoo packages. The backtrace is the same as in comment #5. I also haven't been able to produce these crashes in any app other than konqueror.
*** Bug 79768 has been marked as a duplicate of this bug. ***
In KDE 3.2.2, Konqueror and KDesktop still crash every day. I have started to loose my habit of dragging things in KDE when there are any Konqueror windows around. So far, I have not been very successful and I even accidentally crashed this Konqueror window while I was writing this comment.. :((( This is a *very* nasty bug that should not exist in a x.2.2 release. Therefore, I changed the priority and severity of this bug to HI/MAJOR. I guess this is the right thing to do. I also changes the title, since the crashes also occur when dragging things quite slowly.
*** Bug 81184 has been marked as a duplicate of this bug. ***
Dik Takken: First of all, please do not touch the priority field unless the bug is assigned to you or the maintainer told you to do so. Second, what backtrace do you get?
As the submitter of bug #81184 I think I should add my 2c. In my experience it doesn't matter where you drag from. You can open two konqueror file managers and drag from one to the other. Also even though it doesn't always crash, it is in my experience always possible to provoke it to crash by quickly moving the dragged object (fully) out of the window and then move it back in. Do it many times, and do it a bit quickly, and it always crashes for me. When it crashes it seems to take the desktop with it, but it mostly reinitialises automatically without problems. Sometimes it doesn't though and you end up with a blank desktop without icons. I have also had it crash the desktop without crashing konqueror first.
> First of all, please do not touch the priority field unless the bug is assigned to you or the maintainer told you to do so. My apologies, since I have access to the controls that set the priority, I guessed I had the right to use them as well. I guess the correct code of conduct regarding this control is of the 'look, but don't touch' sort. I am currently recompiling konqueror in order to get a decent backtrace. I will post my findings as soon as my machine finishes crunching code..
I recompiled the konqueror subdirectory in kdebase using no compiler flags and the --with-debug=full configure option. Also, I disabled preloading of konqueror. When I crash konqueror, I get this message: This backtrace appears to be useless. This is probably because your packages are built in a way which prevents creating of proper backtraces, or the stack frame was seriously corrupted in the crash. (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[New Thread 8192 (LWP 31432)] 0x420ae169 in wait4 () from /lib/i686/libc.so.6 #0 0x420ae169 in wait4 () from /lib/i686/libc.so.6 #1 0x4212a2d0 in __DTOR_END__ () from /lib/i686/libc.so.6 #2 0x41040c63 in waitpid () from /lib/i686/libpthread.so.0 #3 0x4063e8ea in KCrash::defaultCrashHandler () from /usr/local/kde/lib/libkdecore.so.4 #4 0x00000004 in ?? () What can I do?
Dik: you'll probably have to recompile qt and kdelibs with debug as well in order to get a useful backtrace. You should also recompile the libkonq subdirectory in kdebase with debug too. Hope this helps.
Well, before recompiling lots of things, I'd suggest first trying the following: running the test konqueror in gdb. Sometimes gdb can't get backtraces when invoked from dr.konqui, but works fine when the app is run through it. I'd do the following: gdb konqueror run <do stuff to make it crash> bt
Thanks for helping me out, Dr Konqi did not do it's job. Here is my backtrace: Program received signal SIGSEGV, Segmentation fault. 0x4006fe6b in KonqView::eventFilter (this=0x8260708, obj=0x8273240, e=0xbfffef30) at konq_view.cc:1156 1156 QObjectList *children = m_pPart->widget()->queryList( "QWidget"); Current language: auto; currently c++ (gdb) backtrace #0 0x4006fe6b in KonqView::eventFilter (this=0x8260708, obj=0x8273240, e=0xbfffef30) at konq_view.cc:1156 #1 0x40b1ec48 in QObject::activate_filters () from /usr/local/qt/lib/libqt-mt.so.3 #2 0x08384c48 in ?? () #3 0x000000e1 in ?? ()
On a hunch this could be qt related i did some testing in other apps. I tried to make kaffeine, which accepts media file drops, and kmails composer, which will accept any kind of file dropped on it as an attachment, crash but it didn't work. I tried moving the drop icon over the windows at least 50 times, reasonably fast, and they worked as expected. Then I tried it again with konqueror and it crashed after moving the icon in and out of the window perhaps five times. So it seems to specific to konqueror.
Been trying hard to reproduce this crash with cvs head from 06.07.2004. But I'm not able to crash Konqy :-) Is this fixed for other people or am I just a bad crasher? Cheers Jo
I noticed that it's much harder to crash it when you have compiled it for debugging. I guess it crashes more easily when it runs faster. This might also explain why some people never crash it and other people crash it dayly. The bug is propably a timing problem.
Hi, I have a very similar issue here on Debian/Alpha. I recompiled QT and konqueror to prevent stripping (-g is default at Debian) but otherwise unchanged. My backtrace looks slightly different from those above, so maybe it is of some help. I used reportbug from Debian to gather all information, it has not been reported there though. Subject: konqueror: Crashes (sometimes) on drag&drop Package: konqueror Version: 4:3.2.2-1 Severity: normal Sometimes (seems to depend on the speed of the mouse movement, but I am not sure), the following happens: I start dragging one/several files by keeping Ctrl pressed while moving the mouse. During dragging, I pass over another konqueror window. About every 10th time, this window crashes. I rebuild unstripped versions of konqueror and qt. Now I get a crash window which does not claim to be useless. Backtrce follows, if you need more/other info, please tell me which (and note that I am on alpha, not x86): Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 922)] 0x0000020001a2a390 in waitpid () from /lib/libpthread.so.0 #0 0x0000020001a2a390 in waitpid () from /lib/libpthread.so.0 #1 0x0000020000d38930 in KCrash::defaultCrashHandler () from /usr/lib/libkdecore.so.4 #2 0x0000020001a29458 in __pthread_sighandler () from /lib/libpthread.so.0 #3 0x0000020001e4f830 in sigset () from /lib/libc.so.6.1 #4 0x00000200012c7314 in QFont::QFont () from /usr/lib/libqt-mt.so.3 #5 0x0000020001250a44 in QPainter::begin () from /usr/lib/libqt-mt.so.3 #6 0x00000200015645a4 in QIconView::drawDragShapes () from /usr/lib/libqt-mt.so.3 #7 0x000002000155fec8 in QIconView::contentsDragEnterEvent () from /usr/lib/libqt-mt.so.3 #8 0x0000020000210844 in KonqIconViewWidget::contentsDragEnterEvent ( this=0x120230ce0, e=0x11fffee80) at konq_iconviewwidget.cc:1177 #9 0x0000020001484cf8 in QScrollView::viewportDragEnterEvent () from /usr/lib/libqt-mt.so.3 #10 0x000002000148419c in QScrollView::eventFilter () from /usr/lib/libqt-mt.so.3 #11 0x0000020001564ba4 in QIconView::eventFilter () from /usr/lib/libqt-mt.so.3 #12 0x000002000132392c in QObject::activate_filters () from /usr/lib/libqt-mt.so.3 #13 0x0000020001323810 in QObject::event () from /usr/lib/libqt-mt.so.3 #14 0x000002000136d408 in QWidget::event () from /usr/lib/libqt-mt.so.3 #15 0x00000200012ab834 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3 #16 0x00000200012aac9c in QApplication::notify () from /usr/lib/libqt-mt.so.3 #17 0x0000020000c89588 in KApplication::notify () from /usr/lib/libkdecore.so.4 #18 0x00000200012379f4 in qt_handle_xdnd_position () from /usr/lib/libqt-mt.so.3 #19 0x0000020001221614 in QApplication::x11ClientMessage () from /usr/lib/libqt-mt.so.3 #20 0x00000200012229b8 in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3 #21 0x000002000123dd80 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #22 0x00000200012c5564 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #23 0x00000200012c537c in QEventLoop::exec () from /usr/lib/libqt-mt.so.3 #24 0x00000200012abb40 in QApplication::exec () from /usr/lib/libqt-mt.so.3 #25 0x00000200000b3550 in kdemain (argc=1, argv=0x11ffff878) at konq_main.cc:184 #26 0x0000000120000928 in main (argc=1, argv=0x11ffff878) at konqueror.la.cc:2 -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing') Architecture: alpha Kernel: Linux 2.4.26 Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro Versions of packages konqueror depends on: ii kcontrol 4:3.2.2-1 KDE Control Center ii kdebase-kio-plugins 4:3.2.2-1 KDE I/O Slaves ii kdelibs4 4:3.2.2-2 KDE core libraries ii kdesktop 4:3.2.2-1 KDE Desktop ii kfind 4:3.2.2-1 KDE File Find Utility ii libart-2.0-2 2.3.16-5 Library of functions for 2D graphi ii libc6.1 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-5 client library to control the FAM ii libgcc1 1:3.3.4-2 GCC support library ii libice6 4.3.0.dfsg.1-4 Inter-Client Exchange library ii libjpeg62 6b-9 The Independent JPEG Group's JPEG ii libkonq4 4:3.2.2-1 Core libraries for KDE's file mana ii libpcre3 4.5-1.1 Perl 5 Compatible Regular Expressi ii libpng12-0 1.2.5.0-6 PNG library - runtime ii libqt3c102-mt 3:3.2.3-4 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0.dfsg.1-4 X Window System Session Management ii libstdc++5 1:3.3.4-2 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-4 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-4 X Window System miscellaneous exte ii libxrender1 0.8.3-7 X Rendering Extension client libra ii xlibs 4.3.0.dfsg.1-4 X Window System client libraries m ii zlib1g 1:1.2.1.1-3 compression library - runtime -- debconf information: * konqueror/crypto:
I've never experienced this bug by accident, but am able to reproduce it by dragging an icon over a konqueror window really fast for a while. I started konqueror like so: machinename:~ $ konqueror --profile filemanagement konqueror: WARNING: KGenericFactory: instance requested but no instance name passed to the constructor! Then I start dragging the icon from the desktop randomly over the window. After a while konqueror will crash, taking the desktop and icons with it about one in every three times. But most importantly, when it crashes I get this message on the console: QClipboard: internal error, qt_xclb_wait_for_event recursed I'm surprised that no one else has mentioned this. Perhaps it only does this on my machine.
Yes, I get exactly the same message in ~/.xsession-errors: QClipboard: internal error, qt_xclb_wait_for_event recursed X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 Minor opcode: 0 Resource id: 0x2e000f8 *** kdesktop (1660) got signal 11
I think it's been fixed in KDE 3.3 Beta 1. I am an exceptionally good crasher, but all my attempts failed miserably. :) Shall I close this bug?
On Friday 23 July 2004 13:36, Dik Takken wrote: > Shall I close this bug? I didnt see this bug anymore, so i think it's OK :) Wilbert
*** Bug has been marked as fixed ***.