Bug 50225 - kicker crash when mouse goes "crazy"
Summary: kicker crash when mouse goes "crazy"
Status: RESOLVED FIXED
Alias: None
Product: kicker
Classification: Plasma
Component: general (show other bugs)
Version: 1.1
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: John Firebaugh
URL:
Keywords:
: 52294 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-11-05 12:03 UTC by Cp Hennessy
Modified: 2003-08-22 20:31 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 Cp Hennessy 2002-11-05 12:03:29 UTC
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
Comment 1 John Firebaugh 2003-01-07 17:46:07 UTC
*** Bug 52294 has been marked as a duplicate of this bug. ***
Comment 2 Aaron J. Seigo 2003-07-10 09:54:17 UTC
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... 
Comment 3 Aaron J. Seigo 2003-08-22 20:31:31 UTC
*** Bug has been marked as fixed ***.