launching app, crashes lxqt-panel

[damianatorrpm]

Attempting to launch a program crashes the panel and whole session, if:

1. There is already a running (but frozen / hanging / crashed) instance
2. In the desktop file it is marked as DBus Activatable

How to reproduce:

1. Use lxqt
2. Open terminal
3. Run e.g gnome-maps (or a program which has DBusActivatable=true in its desktop file)
4. Hit ctrl + z
5. Try to open gnome-maps from lxqt-panel-menu
6. Everything freezes
   (Recent DBusActivatable version required of course)

Changing the value in the desktop file from
DBusActivatable=true
to
DBusActivatable=false

PS: if the program is dbus activatable and just has a slow startup the ui freezes until it starts

confirms this is the issue (the session and panel do not freeze with DBusActivatable=false)

[tsujan]

I installed gnome-maps (very reluctantly), saw DBusActivatable was true in its desktop file and launched it from lxqt-panel. The menu was frozen for a second or so but then, gnome-maps started without problem. No crash anywhere.

The one-sec freeze -- ONLY in the panel and nowhere else --- was suspicious but everything related to gnome is suspicious too.

Please:

• Add the version of your installed lxqt-panel to your report; and
• When you see a crash, add a backtrace (by using coredumpctl ... and where).

[tsujan]

I tested gnome-maps on another computer with the same version of LXQt and the panel was restarted after a crash:

#0  0x00007f19a87fcf4e in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6
#1  0x00007f19a8b05e81 in QListData::remove(int) () from /usr/lib/libQt5Core.so.5
#2  0x00007f19a8b0618a in QListData::erase(void**) () from /usr/lib/libQt5Core.so.5
#3  0x000055a36d808b84 in ?? ()
#4  0x00007f19a8c6abab in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) ()
   from /usr/lib/libQt5Core.so.5
#5  0x00007f19a963be14 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#6  0x00007f19a96436e1 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#7  0x00007f19a8c6ae99 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#8  0x00007f19a9677c11 in QWidgetPrivate::close_helper(QWidgetPrivate::CloseMode) ()
   from /usr/lib/libQt5Widgets.so.5
#9  0x00007f19a97b9730 in ?? () from /usr/lib/libQt5Widgets.so.5
#10 0x00007f19a97b9ba0 in ?? () from /usr/lib/libQt5Widgets.so.5
#11 0x00007f19a97bb478 in QMenu::mousePressEvent(QMouseEvent*) () from /usr/lib/libQt5Widgets.so.5
#12 0x00007f19a967d64f in QWidget::event(QEvent*) () from /usr/lib/libQt5Widgets.so.5
#13 0x00007f19a97bd36c in QMenu::event(QEvent*) () from /usr/lib/libQt5Widgets.so.5
#14 0x00007f19a9c45e66 in XdgMenuWidget::event(QEvent*) () from /usr/lib/libQt5Xdg.so.3
#15 0x00007f19a963be24 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#16 0x00007f19a9643929 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#17 0x00007f19a8c6ae99 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#18 0x00007f19a9642c08 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool, bool) () from /usr/lib/libQt5Widgets.so.5
#19 0x00007f19a9697e93 in ?? () from /usr/lib/libQt5Widgets.so.5
#20 0x00007f19a969af87 in ?? () from /usr/lib/libQt5Widgets.so.5
#21 0x00007f19a963be24 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#22 0x00007f19a96436e1 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#23 0x00007f19a8c6ae99 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#24 0x00007f19a903d96e in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) ()
   from /usr/lib/libQt5Gui.so.5
#25 0x00007f19a903d492 in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) ()
   from /usr/lib/libQt5Gui.so.5
#26 0x00007f19a903edd6 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /usr/lib/libQt5Gui.so.5
#27 0x00007f19a901875c in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/libQt5Gui.so.5
#28 0x00007f19a4ab790c in ?? () from /usr/lib/libQt5XcbQpa.so.5
#29 0x00007f19a757aa2f in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#30 0x00007f19a757c5e9 in ?? () from /usr/lib/libglib-2.0.so.0
#31 0x00007f19a757c62e in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#32 0x00007f19a8cc0ce9 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/libQt5Core.so.5
#33 0x00007f19a8c69b2c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#34 0x00007f19a8c71e36 in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#35 0x000055a36d804096 in ?? ()
#36 0x00007f19a86c1223 in __libc_start_main () from /usr/lib/libc.so.6
#37 0x000055a36d80479e in _start ()

The second, third,... time I launched gnome-maps, no crash happened.

An interesting thing in the above backtrace is that there 's no trace of lxqt in it.

[tsujan]

I was wrong: XdgMenuWidget is there, which means libqtxdg.

[damianatorrpm]

I am confident the bug is in xdgdesktopfile.cpp
startDetached()
-> startbyDbus

somewhere here:

    QDBusInterface app(f.completeBaseName(), path, QLatin1String("org.freedesktop.Application"));
    //Note: after the QDBusInterface construction, it can *invalid* (has reasonable lastError())
    // but this can be due to some intermediate DBus call(s) which doesn't need to be fatal and
    // our next call() can succeed
    // see discussion https://github.com/lxqt/libqtxdg/pull/75
    if (app.lastError().isValid())
    {
        qWarning().noquote() << "XdgDesktopFileData::startByDBus: invalid interface:" << app.lastError().message()
            << ", but trying to continue...";
    }
    QDBusMessage reply;
    if (!action.isEmpty())
    {

The behaviour of the panel freezing for a second demonstrates (even if you are not able to reproduce the complete hang - which I can reproduce every time) that something is wrong, the panel (XdgDesktopfile->startDetached) should not freeze while waiting for a response from the called application.
I could dig further and try to fix the bug myself in the code, but I am very reluctant to that as previous pull request by me are ignored, e.g:
lxqt/liblxqt#212

I don't think that coredumpctl has useful output here

                Stack trace of thread 17411:
                #0  0x00007fe0ff92fa97 __poll (libc.so.6)
                #1  0x00007fe0fed102ae n/a (libglib-2.0.so.0)
                #2  0x00007fe0fed103e3 g_main_context_iteration (libglib-2.0.so.0)
                #3  0x00007fe0ffeb24b2 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
                #4  0x00007fe0ffe5c41b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
                #5  0x00007fe0ffcb5745 _ZN7QThread4execEv (libQt5Core.so.5)
                #6  0x00007fe100d57f3b n/a (libQt5DBus.so.5)
                #7  0x00007fe0ffcb68a6 n/a (libQt5Core.so.5)
                #8  0x00007fe0ff76d4c0 start_thread (libpthread.so.0)
                #9  0x00007fe0ff93a8e3 __clone (libc.so.6)

[tsujan]

I am confident the bug is in xdgdesktopfile.cpp

If you have a working patch, please make a PR!

[tsujan]

I could dig further and try to fix the bug myself in the code, but I am very reluctant to that as previous pull request by me are ignored, e.g:...

It's your choice but if you took a look at the dates of other pull requests, you'd know that it isn't ignored. Each LXQt dev has only one head and 2 eyes, which he uses for all of his life activities.

[damianatorrpm]

I attempt to write a patch at the moment.

It's your choice but if you took a look at the dates of other pull requests, you'd know that it isn't ignored. Each LXQt dev has only one head and 2 eyes, which he uses for all of his life activities.

That's true, yet the direction I have seen in the open source community is not that encouraging for anyone willing to commit time, fixes and/or functionality. Other outstanding pull request/discussions/reports to the open source community (not necessarily lxqt, often kde), also see

delays, not necessarily our bug, need to install app from other toolkit, don't need that functionality for our usecase etc. etc. etc attitude

The lxqt pr mentioned above is still quite recent, I'll give it some time.
Sometimes additional comments can help new contributors in a right direction.
E.g "policykit is not designed to do it that way" or "that would require x, y"
"this is not related to a desktop environment?"

[tsujan]

I write the following lines because I value your contribution but think you have a wrong image of it. They're about my own experience.

(1) I made the same mistake you're making years ago -- had made a patch for an LXQt component but it was "ignored" for a long time and I got reluctant to do more at first. Now, I'm an LXQt member ;) That shows something but I don't have time to go into details here.

(2) As a dev with an experience of working with other devs, 2 years ago, I made 2 patches for Dolphin to give it 2 features that were missing from it but were added to pcmanfm-qt -- while I was an LXQt dev and even didn't use Dolphin. After 7 months, I received 2 emails. I had to think for a few seconds to remember what I'd done 7 months ago. This time, I wasn't surprised because I knew that each of KDE devs had only one head, like me ;) The short discussion between that KDE dev and me was based on mutual understanding. Now, Dolphin has the feature I wanted it to have (selecting a folder on going up from inside it).

(3) Sometimes, devs reject a PR. For example, the first Dolphin patch I sent was practically rejected but Dolphin's main dev did it in another way (although I think my way was more frugal). The second patch was totally rejected because the problem was deeper (as I'd mentioned in the patch comment). I wasn't disappointed at all because I knew they had right to reject my proposals and patches. Yes, developers have that right!

Now, if you're still reluctant or disappointed, I can't do anything more. If not, welcome to LXQt!

[damianatorrpm]

Thank you for the explanation. For now I will refrain from commenting on the "contributing arguments" further.
The problem with lxqt-panel (and anything using libqtxdg) is though not directly with lxqt or libqtxdg.

The QDBusInterface freezes on construction if the interface corresponds to a frozen application.
https://bugreports.qt.io/browse/QTBUG-75016

which freezes all kind of stuff (qdbusviewer & co) as well.

For my uses I have disabled dbus activation completely until fixed by commenting

        if (startByDBus(action, urls)) 
            return true;

[tsujan]

https://bugreports.qt.io/browse/QTBUG-75016

Nice info. Thanks!

[palinek]

@damianatorrpm please, have a look on #182