Hi, On Fri, Nov 7, 2014 at 1:12 PM, René J.V. <rjvber...@gmail.com> wrote:
> On Friday November 07 2014 12:44:27 Andreas Pakulat wrote: > >Looking at that backtrace I don't see UserInput events. At least > >QTimerInfoList::activateTimers suggests a QTimer fires, thats not a > >UserInput nor a UserInterface event. > > You may be right, I noticed that too. Sadly it's not easy to do > post-mortem debugging here. I actually *use* the software, running in full > debug mode would likely make it unbearably slow :) and I know too little of > KDE's PIM APIs. > > This backtrace however doesn't seem to imply a timer but rather a true UI > event: > https://bugs.kde.org/show_bug.cgi?id=340624 I don't see any user input events there either. The crash is triggered from an invokeMethod call which seems to be triggered from a dbus connection. So even if the dbus message is triggered through a user event (like clicking in the menubar or so) thats not possible for Qt to see anymore since a dbus event may also come from a commandline app running in the background or something else. So if libdbusmenu-qt just invoke's qactions or their connected slots directly when the user selects something in the menu (I'm assuming this is the hack that (K)Ubuntu uses since some releases to get a cross-application menubar like on MacOSX) instead of posting a user-input event to the event loop you could argue they're doing that wrong. One could also argue that the menu shouldn't be accessible anymore during this 'shutdown' procedure... Andreas
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
