Version: 1.1 (using KDE 3.0.9 (KDE 3.1 RC1)) Installed from: compiled sources Compiler: gcc version 3.2 OS: Linux (i686) release 2.4.19 Hi, I had a small problem where my mouse would go "crazy", moving around the lower left part of the screen near the "K" button and other buttons in kicker, with strange mouse button clicks being generated. This is obviously not a KDE problem. However I think that kicker should not crash because of this. I got the following crash due to the setup above. I hope that there is enough here to help prevent this possibility in the future. [New Thread 1024 (LWP 8582)] 0x167268c9 in wait4 () from /lib/libc.so.6 #0 0x167268c9 in wait4 () from /lib/libc.so.6 #1 0x167a1c90 in __DTOR_END__ () from /lib/libc.so.6 #2 0x16581a93 in waitpid () from /lib/libpthread.so.0 #3 0x15beadec in KCrash::defaultCrashHandler(int) (sig=11) at kcrash.cpp:235 #4 0x1657f12b in pthread_sighandler () from /lib/libpthread.so.0 #5 <signal handler called> #6 0x160cdf1c in QMenuData::count() const (this=0x827f990) at widgets/qmenudata.cpp:234 #7 0x16b3437e in BaseContainer::reduceMenu(QPopupMenu*) (menu=0x3fffe35c) at container_base.cpp:93 #8 0x16b3432c in BaseContainer::opMenu() (this=0x817d8c8) at container_base.cpp:88 #9 0x16b39785 in ButtonContainer::eventFilter(QObject*, QEvent*) ( this=0x817d8c8, o=0x0, e=0x817d8c8) at container_button.cpp:137 #10 0x15fd8eca in QObject::activate_filters(QEvent*) (this=0x817e0a8, e=0x3fffeaa0) at kernel/qobject.cpp:827 #11 0x15fd8d3c in QObject::event(QEvent*) (this=0x817e0a8, e=0x3fffeaa0) at kernel/qobject.cpp:660 #12 0x16011a46 in QWidget::event(QEvent*) (this=0x817e0a8, e=0x3fffeaa0) at kernel/qwidget.cpp:4305 #13 0x15f74e6c in QApplication::internalNotify(QObject*, QEvent*) ( this=0x3fffeea0, receiver=0x817e0a8, e=0x3fffeaa0) at kernel/qapplication.cpp:2300 #14 0x15f74674 in QApplication::notify(QObject*, QEvent*) (this=0x3fffeea0, receiver=0x817e0a8, e=0x3fffeaa0) at kernel/qapplication.cpp:2108 #15 0x15b5dc59 in KApplication::notify(QObject*, QEvent*) (this=0xfffffe00, receiver=0x817e0a8, event=0x3fffeaa0) at kapplication.cpp:441 #16 0x15f1a747 in QApplication::sendSpontaneousEvent(QObject*, QEvent*) ( receiver=0x817e0a8, event=0x3fffeaa0) at kernel/qapplication.h:480 #17 0x15f13b27 in QETWidget::translateMouseEvent(_XEvent const*) ( this=0x817e0a8, event=0x3fffed50) at kernel/qapplication_x11.cpp:4230 #18 0x15f117d2 in QApplication::x11ProcessEvent(_XEvent*) (this=0x3fffeea0, event=0x3fffed50) at kernel/qapplication_x11.cpp:3383 #19 0x15f297c6 in QEventLoop::processEvents(unsigned) (this=0x80a4ba8, flags=4) at kernel/qeventloop_x11.cpp:171 #20 0x15f8b416 in QEventLoop::enterLoop() (this=0x80a4ba8) at kernel/qeventloop.cpp:191 #21 0x15f8b332 in QEventLoop::exec() (this=0x80a4ba8) at kernel/qeventloop.cpp:138 #22 0x15f74fef in QApplication::exec() (this=0x3fffeea0) at kernel/qapplication.cpp:2421 #23 0x16b23797 in main (argc=-512, argv=0x805cdd0) at main.cpp:148 #24 0x0804cc36 in launch (argc=1, _name=0x805f07c "kicker", args=0x805f083 "", cwd=0x0, envc=0, envs=0x8051bb8 "d
*** Bug 52294 has been marked as a duplicate of this bug. ***
i'm guessing this is because in ButtonContainer::eventFilter, and a few other places that get called from there, QApplication::processEvents() gets called. so if there is a barrage of mouse activity, i wouldn't be surprised if another event sneaks in the door while the first one is still being processed. this could likely happen several times in a row. i've got a patch that i will commit later on that effectively stops this from being able to happen. i'm just testing it now...
*** Bug has been marked as fixed ***.