if I disable compositing the crash goes away.  I have a similar crash with konquerer that also goes away if compositing is disabled.

is it related to kwin's compositing or compositing in general
(can you try "compiz --replace"?)

compositing in general -- with compiz it did the same thing.

i blame plasma's compositing aware skinning support or dbusmenus usage of it then.

I have noticed that it has to be restarted in order for it not to crash once compositing has been disabled.  If kate is started with compositing on, it will crash by clicking "new", "close" etc.  However if I start it with compositing off, then it won't crash.  Just thought I would throw those details in there.

ok it is ARGB transparency.  I am currently using oxygen-argb (which crashes it).  it will also crash with Bespin with ARGB.  However, disabling ARGB fixes the crash.

You could try with xbar instead of dbus menu then, but it's likely that the latter ignores but somehow relies on the depth of the (render) visual =\

can you get longer backtraces (ie. deeper than "#7  QAction::menu")

I ran kate in gdb and crashed it.  It said:


Program received signal SIGSEGV, Segmentation fault.
0x003bbcea in QAction::menu (this=0x82ce948) at kernel/qaction.cpp:748
748     kernel/qaction.cpp: No such file or directory.
        in kernel/qaction.cpp
(gdb) backtrace 
#0  0x003bbcea in QAction::menu (this=0x82ce948) at kernel/qaction.cpp:748
#1  0x00b26d94 in DBusMenuExporterDBus::GetChildren (this=0x82c1af0, parentId=408, names=...) at ../3rdparty/dbusmenu-qt/src/dbusmenuexporterdbus_p.cpp:47
#2  0x00b3f708 in DBusMenuExporterDBus::qt_metacall (this=0x82c1af0, _c=QMetaObject::InvokeMetaMethod, _id=4, _a=0xbfffe27c)
    at .moc/release-shared/moc_dbusmenuexporterdbus_p.cpp:106
#3  0x0144a9dc in QDBusConnectionPrivate::deliverCall (this=0x8066ac8, object=0x82c1af0, msg=..., metaTypes=..., slotIdx=8) at qdbusintegrator.cpp:919
#4  0x0144bd25 in QDBusConnectionPrivate::activateCall (this=0x8066ac8, object=0x82c1af0, flags=4080, msg=...) at qdbusintegrator.cpp:829
#5  0x0144c49c in QDBusConnectionPrivate::activateObject (this=0x8066ac8, node=..., msg=..., pathStartPos=10) at qdbusintegrator.cpp:1399
#6  0x0144ca2a in QDBusActivateObjectEvent::placeMetaCall (this=0x8620070) at qdbusintegrator.cpp:1493
#7  0x0161c6a2 in QObject::event (this=0x82c1af0, e=0x84d5720) at kernel/qobject.cpp:1219
#8  0x003c3fdc in QApplicationPrivate::notify_helper (this=0x806aee0, receiver=0x82c1af0, e=0x8620070) at kernel/qapplication.cpp:4396
#9  0x003ca04e in QApplication::notify (this=0xbfffecfc, receiver=0x82c1af0, e=0x8620070) at kernel/qapplication.cpp:3798
#10 0x0124bcfa in KApplication::notify (this=0xbfffecfc, receiver=0x82c1af0, event=0x8620070) at ../../kdeui/kernel/kapplication.cpp:310
#11 0x01609b3b in QCoreApplication::notifyInternal (this=0xbfffecfc, receiver=0x82c1af0, event=0x8620070) at kernel/qcoreapplication.cpp:732
#12 0x0160cd8b in sendEvent (receiver=0x0, event_type=0, data=0x804ee98) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
#13 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x804ee98) at kernel/qcoreapplication.cpp:1373
#14 0x0160cf4d in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1266
#15 0x01638a74 in sendPostedEvents (s=0x806d730) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:220
#16 postEventSourceDispatch (s=0x806d730) at kernel/qeventdispatcher_glib.cpp:277
#17 0x018c7855 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#18 0x018cb668 in ?? () from /lib/libglib-2.0.so.0
#19 0x018cb848 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#20 0x01638565 in QEventDispatcherGlib::processEvents (this=0x804eb58, flags=...) at kernel/qeventdispatcher_glib.cpp:415
#21 0x00485be5 in QGuiEventDispatcherGlib::processEvents (this=0x804eb58, flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#22 0x01608609 in QEventLoop::processEvents (this=0xbfffebf4, flags=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece.
) at kernel/qeventloop.cpp:149
#23 0x01608a8a in QEventLoop::exec (this=0xbfffebf4, flags=...) at kernel/qeventloop.cpp:201
#24 0x0160d00f in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1009
#25 0x003c2e07 in QApplication::exec () at kernel/qapplication.cpp:3672
#26 0x001347b7 in kdemain () from /usr/lib/kde4/libkdeinit/libkdeinit4_kate.so
#27 0x0804859b in _start ()
(gdb) 


I don't really know how to get a longer one.

You were right, kate is fine with argb bespin and xbar.

you don't the trace is complete. my vague guess is that dbusmenu operates on a window type qwidget and it's x drawable which gets lost when setting the translucency flag (qt "silently" replaces the X drawable, ie. native window) and therefore stumbles over a dangeling pointer, but you should ask Aurélien on this...

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

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

[Comment from a bug triager]
Bug 257585 and bug 241060 both have similar backtraces (but under different
situations with other KDE apps) so they all may have a common root issue.

(I am dbusmenu-qt maintainer) Interestingly, dbusmenu does not care about compositing: all it does is go through all the items of the menubar and expose them on dbus.

I can't reproduce the bug here (Ubuntu 10.10, KDE 4.5.2, just like you), but I am going to investigate nevertheless.

@aurelian
see comment #9 - setting the translucency flag changes the window (native) so if you've connections to QWidget::winId() before and after the change (usually happens at QStyle::polish(QWidget*), you might end up dealing with the wrong client...

(In reply to comment #14)
> @aurelian
> see comment #9 - setting the translucency flag changes the window (native) so
> if you've connections to QWidget::winId() before and after the change (usually
> happens at QStyle::polish(QWidget*), you might end up dealing with the wrong
> client...

Very good point, I missed the fact the reporter was using oxygen-transparent. I just installed this style and can now reproduce the crash.

Fixed in upcoming dbusmenu-qt 0.6.5. Would be great to get confirmation about the fix if you can build dbusmenu-qt from git.

I did "git clone git://gitorious.org/dbusmenu/dbusmenu-qt.git" and compiled and installed the resulting program, ran kbuildsycoca4 --noincremental logged out and back in, but kate still crashes under the same situation with this backtrace:

"
Application: Kate (kate), signal: Segmentation fault
[KCrash Handler]
#7  QList (this=0x6c) at ../../include/QtCore/../../src/corelib/tools/qlist.h:118
#8  QWidget::actions (this=0x6c) at kernel/qwidget.cpp:3181
#9  0x01515e8d in DBusMenuExporterDBus::GetChildren (this=0x8ebeea0, parentId=408, names=...) at ../3rdparty/dbusmenu-qt/src/dbusmenuexporterdbus_p.cpp:53
#10 0x0152e708 in DBusMenuExporterDBus::qt_metacall (this=0x8ebeea0, _c=QMetaObject::InvokeMetaMethod, _id=4, _a=0xbfd852dc) at .moc/release-shared/moc_dbusmenuexporterdbus_p.cpp:106
#11 0x004409dc in QDBusConnectionPrivate::deliverCall (this=0x8beb210, object=0x8ebeea0, msg=..., metaTypes=..., slotIdx=8) at qdbusintegrator.cpp:919
#12 0x00441d25 in QDBusConnectionPrivate::activateCall (this=0x8beb210, object=0x8ebeea0, flags=4080, msg=...) at qdbusintegrator.cpp:829
#13 0x0044249c in QDBusConnectionPrivate::activateObject (this=0x8beb210, node=..., msg=..., pathStartPos=10) at qdbusintegrator.cpp:1399
#14 0x00442a2a in QDBusActivateObjectEvent::placeMetaCall (this=0x90ab5f8) at qdbusintegrator.cpp:1493
#15 0x0067b6a2 in QObject::event (this=0x8ebeea0, e=0xbfd85128) at kernel/qobject.cpp:1219
#16 0x00db2fdc in QApplicationPrivate::notify_helper (this=0x8bf3548, receiver=0x8ebeea0, e=0x90ab5f8) at kernel/qapplication.cpp:4396
#17 0x00db904e in QApplication::notify (this=0xbfd85d5c, receiver=0x8ebeea0, e=0x90ab5f8) at kernel/qapplication.cpp:3798
#18 0x03ab905a in KApplication::notify (this=0xbfd85d5c, receiver=0x8ebeea0, event=0x90ab5f8) at ../../kdeui/kernel/kapplication.cpp:310
#19 0x00668b3b in QCoreApplication::notifyInternal (this=0xbfd85d5c, receiver=0x8ebeea0, event=0x90ab5f8) at kernel/qcoreapplication.cpp:732
#20 0x0066bd8b in sendEvent (receiver=0x0, event_type=0, data=0x8bd2e98) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
#21 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x8bd2e98) at kernel/qcoreapplication.cpp:1373
#22 0x0066bf4d in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1266
#23 0x00697a74 in sendPostedEvents (s=0x8bf5728) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:220
#24 postEventSourceDispatch (s=0x8bf5728) at kernel/qeventdispatcher_glib.cpp:277
#25 0x00a3c855 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#26 0x00a40668 in ?? () from /lib/libglib-2.0.so.0
#27 0x00a40848 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#28 0x00697565 in QEventDispatcherGlib::processEvents (this=0x8bd2b58, flags=...) at kernel/qeventdispatcher_glib.cpp:415
#29 0x00e74be5 in QGuiEventDispatcherGlib::processEvents (this=0x8bd2b58, flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#30 0x00667609 in QEventLoop::processEvents (this=0xbfd85c54, flags=) at kernel/qeventloop.cpp:149
#31 0x00667a8a in QEventLoop::exec (this=0xbfd85c54, flags=...) at kernel/qeventloop.cpp:201
#32 0x0066c00f in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1009
#33 0x00db1e07 in QApplication::exec () at kernel/qapplication.cpp:3672
#34 0x00bc37b7 in kdemain () from /usr/lib/kde4/libkdeinit/libkdeinit4_kate.so
#35 0x0804859b in _start ()
"

Note that I did not uninstall my currently installed version of dbus menu qt, I figured that the new compile would overwrite it.  Please correct me if I am wrong.

[Comment from a bug triager]
- Check if the installation path of your compiled version is the same as the default one.
The path of the code in the backtrace doesn't seem to match a "locally/manually" installed version:

example: in

#9  0x01515e8d in DBusMenuExporterDBus::GetChildren (this=0x8ebeea0,
parentId=408, names=...) at
../3rdparty/dbusmenu-qt/src/dbusmenuexporterdbus_p.cpp:53

"../3rdparty/dbusmenu-qt/src/dbusmenuexporterdbus_p.cpp:53" could be something like "/home/user/buildpath/src/dbusmenuexporterdbus_p.cpp:53"

Regards

My cmake install prefix is /usr.  I have compared the output from "make install" and the package listing from synaptic.  The .so is getting installed in /usr/lib, which is the correct location.  I have noticed however, that the library I compiled from git installs libdbusmenu-qt.so.2.3.2 in /usr/lib, while my kubuntu package is libdbusmenu-qt.so.2.3.4.

Also, I did not set the CMAKE_BUILD_TYPE flag in ccmake, could that be the problem?  

Sorry, I am new at this!

I messed up with the version numbers, that is why dbusmenu-qt version 0.6.5 came with a library version of 2.3.2... I released version 0.6.6 to fix this.

Unfortunately this new release actually won't help you much because the patch is in Qt. Kubuntu version of Qt has been patched for appmenu support, but because of circular dependencies the appmenu patch includes its own copy of dbusmenu-qt. This patch needs to be updated to include the new dbusmenu-qt.

I want to avoid this duplication for the next Kubuntu release, but I am afraid that for now unless you rebuild Qt yourself, you will have to either disable appmenu or use the regular Oxygen style.

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

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