Bug 252602

*** Bug 247342 has been marked as a duplicate of this bug. ***

*** Bug 269292 has been marked as a duplicate of this bug. ***

*** Bug 279726 has been marked as a duplicate of this bug. ***

*** Bug 243224 has been marked as a duplicate of this bug. ***

Hi,

I can't reproduce this bug with kde 4.6.5, qt 4.7.3, konsole 2.6.4 with Description Step and
247342, 247010 marked as duplicate.

anyone?

This does happen occasionally. Haven't found a sure way to reproduce it.

Ok, I found a way to reproduce similar crash with high probability.

1).open 30+ tabs running shell.
2).press 'Ctrl-D' to close current shell/tab, but do not release the key.
3).more tabs are closed quickly and at some point konsole crashes.

#7, I tried half-dozen times w/ 50+ tabs and couldn't get trunk to crash.

(In reply to comment #8)
> #7, I tried half-dozen times w/ 50+ tabs and couldn't get trunk to crash.

Well, there is another important condition I did not notice: ibus is used as the input method platform and is running. If ibus is not running, the steps metioned in comment #7 does not work as expected. 

Here is my environment variables related with ibus:

export XMODIFIERS="@im=ibus"
export GTK_IM_MODULE="ibus"
export QT_IM_MODULE="ibus"

*** Bug 286587 has been marked as a duplicate of this bug. ***

*** Bug 291795 has been marked as a duplicate of this bug. ***

I submitted duplicate Bug 291795, and I forgot to mention (since it's relevant) that I was also running ibus.

*** Bug 296758 has been marked as a duplicate of this bug. ***

Created attachment 69998 [details]
New crash information added by DrKonqi

konsole (2.8.1) on KDE Platform 4.8.1 (4.8.1) using Qt 4.8.0

This crash was created by creating a large number of tabs and then holding ctrl-d down. This killed firefox instances and ALL konsole instances.

-- Backtrace (Reduced):
#6  0x0000003201a44871 in QApplication::x11ProcessEvent (this=0x7fff926f4100, event=0x7fff926f3cc0) at kernel/qapplication_x11.cpp:3421
#7  0x0000003201a6c97c in x11EventSourceDispatch (s=0xbb7850, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:148
#8  0x00000037c8844acd in g_main_dispatch (context=0xbb64e0) at gmain.c:2441
#9  g_main_context_dispatch (context=0xbb64e0) at gmain.c:3011
#10 0x00000037c88452c8 in g_main_context_iterate (context=0xbb64e0, block=<optimized out>, dispatch=1, self=<optimized out>) at gmain.c:3089

*** Bug 297016 has been marked as a duplicate of this bug. ***

Jekyll,

I don't know about your input method but I have the mouse in the konsole with lots of tabs. Ibus is running. If I hold down ctrl-d... everything dies after just a few tab removals. I do not do anything special. My system is Fedora x86_64 running KDE and is as up to date as I can make it.

George...

*** Bug 298468 has been marked as a duplicate of this bug. ***

I can reproduce it after installing ibus - I'll see if I can find out anything.

#8  0x00ce11e7 in QProcess::waitForStarted(int) () from /opt/project-neon/lib/libQtCore.so.4
#9  0x0037b3aa in Konsole::Pty::start (this=0xa3c33a8, programName=..., programArguments=..., environmentList=...) at /mnt/kde/kde4/trunk/src/kde/kde-baseapps/konsole/src/Pty.cpp:252
#10 0x00388435 in Konsole::Session::run (this=0x9a027f8) at /mnt/kde/kde4/trunk/src/kde/kde-baseapps/konsole/src/Session.cpp:494

I also get this:

QProcessPrivate::createPipe: Cannot create pipe 0x9036b94: Too many open files
QProcessPrivate::createPipe: Cannot create pipe 0x9036b9c: Too many open files
QSocketNotifier: Invalid socket specified
QSocketNotifier: Internal error
QSocketNotifier: Invalid socket specified
QSocketNotifier: Internal error

*** Bug 308787 has been marked as a duplicate of this bug. ***

*** Bug 310509 has been marked as a duplicate of this bug. ***

It looks like the TerminalDisplay is deallocated by QObject::deleteLater(), which is sometimes delivered part-way through processing an X11 event — the IBus input module's processKeyEvent() creates a QEventLoop to speak to DBus, and exec() on that may deliver the deletion event and call ~TerminalDisplay while there's still a reference to the TerminalDisplay on the stack.

Here's the stack trace of the errant destruction:
#0  Konsole::TerminalDisplay::~TerminalDisplay (this=0x5358120, __in_chrg=<optimized out>) at /home/mmullins/debug_konsole/BUILD/konsole-4.12.4/src/TerminalDisplay.cpp:408
#1  0x00007ffff5b65ee8 in QObject::event (this=this@entry=0x5358120, e=e@entry=0x56d7050) at kernel/qobject.cpp:1203
#2  0x00007ffff4a65e33 in QWidget::event (this=this@entry=0x5358120, event=event@entry=0x56d7050) at kernel/qwidget.cpp:8859
#3  0x00007ffff796823a in Konsole::TerminalDisplay::event (this=0x5358120, event=0x56d7050) at /home/mmullins/debug_konsole/BUILD/konsole-4.12.4/src/TerminalDisplay.cpp:2997
#4  0x00007ffff4a12ebc in QApplicationPrivate::notify_helper (this=this@entry=0x6bb550, receiver=receiver@entry=0x5358120, e=e@entry=0x56d7050) at kernel/qapplication.cpp:4565
#5  0x00007ffff4a19825 in QApplication::notify (this=this@entry=0x7fffffffd970, receiver=receiver@entry=0x5358120, e=e@entry=0x56d7050) at kernel/qapplication.cpp:4351
#6  0x00007ffff683cb0a in KApplication::notify (this=0x7fffffffd970, receiver=0x5358120, event=0x56d7050) at /usr/src/debug/kdelibs-4.12.4/kdeui/kernel/kapplication.cpp:311
#7  0x00007ffff5b4cebd in QCoreApplication::notifyInternal (this=0x7fffffffd970, receiver=receiver@entry=0x5358120, event=event@entry=0x56d7050) at kernel/qcoreapplication.cpp:953
#8  0x00007ffff5b500d5 in sendEvent (event=0x56d7050, receiver=0x5358120) at kernel/qcoreapplication.h:231
#9  QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x60e3e0) at kernel/qcoreapplication.cpp:1577
#10 0x00007ffff5b50573 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1470
#11 0x00007ffff5b7c253 in sendPostedEvents () at kernel/qcoreapplication.h:236
#12 postEventSourceDispatch (s=s@entry=0x6bdb90) at kernel/qeventdispatcher_glib.cpp:280
#13 0x00007fffee3a82a6 in g_main_dispatch (context=0x6be170) at gmain.c:3066
#14 g_main_context_dispatch (context=context@entry=0x6be170) at gmain.c:3642
#15 0x00007fffee3a8628 in g_main_context_iterate (context=context@entry=0x6be170, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713
#16 0x00007fffee3a86dc in g_main_context_iteration (context=0x6be170, may_block=1) at gmain.c:3774
#17 0x00007ffff5b7bad5 in QEventDispatcherGlib::processEvents (this=0x60fc90, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#18 0x00007ffff4ab4db6 in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:207
#19 0x00007ffff5b4b95f in QEventLoop::processEvents (this=this@entry=0x7fffffffd100, flags=...) at kernel/qeventloop.cpp:149
#20 0x00007ffff5b4bcad in QEventLoop::exec (this=this@entry=0x7fffffffd100, flags=...) at kernel/qeventloop.cpp:204
#21 0x00007fffd915c575 in IBus::InputContext::processKeyEvent (this=<optimized out>, keyval=<optimized out>, keycode=<optimized out>, state=state@entry=1073741844) at /usr/src/debug/ibus-qt-1.3.3-Source/src/qibusinputcontext.cpp:160
#22 0x00007fffd938b377 in IBusInputContext::x11FilterEvent (this=0x9da500, keywidget=<optimized out>, xevent=0x7fffffffd440) at /usr/src/debug/ibus-qt-1.3.3-Source/qtim/ibus-input-context.cpp:311
#23 0x00007ffff4a8d2e2 in QApplication::x11ProcessEvent (this=0x7fffffffd970, event=event@entry=0x7fffffffd440) at kernel/qapplication_x11.cpp:3345
#24 0x00007ffff4ab4c34 in x11EventSourceDispatch (s=s@entry=0x6be2d0, callback=0x0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:148
#25 0x00007fffee3a82a6 in g_main_dispatch (context=0x6be170) at gmain.c:3066
#26 g_main_context_dispatch (context=context@entry=0x6be170) at gmain.c:3642
#27 0x00007fffee3a8628 in g_main_context_iterate (context=context@entry=0x6be170, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713
#28 0x00007fffee3a86dc in g_main_context_iteration (context=0x6be170, may_block=1) at gmain.c:3774
#29 0x00007ffff5b7bad5 in QEventDispatcherGlib::processEvents (this=0x60fc90, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#30 0x00007ffff4ab4db6 in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:207
#31 0x00007ffff5b4b95f in QEventLoop::processEvents (this=this@entry=0x7fffffffd830, flags=...) at kernel/qeventloop.cpp:149
#32 0x00007ffff5b4bcad in QEventLoop::exec (this=this@entry=0x7fffffffd830, flags=...) at kernel/qeventloop.cpp:204
#33 0x00007ffff5b51399 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1225
#34 0x00007ffff4a1152c in QApplication::exec () at kernel/qapplication.cpp:3823
#35 0x00007ffff7bd2baa in kdemain (argc=4, argv=0x7fffffffdab8) at /home/mmullins/debug_konsole/BUILD/konsole-4.12.4/src/main.cpp:86
#36 0x00007ffff2866d65 in __libc_start_main (main=0x400850 <main(int, char**)>, argc=4, argv=0x7fffffffdab8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdaa8) at libc-start.c:285
#37 0x0000000000400881 in _start ()

The QEventLoop in frame #32 is not the same this pointer as in frame #20.

I suppose a workaround would be to setEnabled(false) at the time the TerminalDisplay is queued for deletion, because after reading the Qt sources, that should prevent the x11FilterEvent call in the first place.  I'm still conflicted whether that belongs in the application, Qt, or if the IBusInputContext needs a rearchitecture.

Matt, thanks for the good analysis! Crash caused by nested event loop in ibus sounds plausible.

If you would like to discuss your workaround with KDE and Qt developers, please open a review request at https://git.reviewboard.kde.org/ and add kdelibs group to reviewers.

That workaround didn't exactly stop it from crashing — I imagine it moved the crashiness around a bit, but definitely not a fix.

If this happens w/ a recent KDE5, please open a new ticket