lxqt-config-monitor: quick termination of session triggers crash

[pmattern]

Terminating LXQt sessions too quickly after starting makes both the KScreen backend and lxqt-config-monitor crash and dump core.

Once settings were saved in lxqt-config-monitor and hence file .config/autostart/lxqt-config-monitor-autostart.desktop is in place several configuration steps take place upon starting LXQt sessions reflected by messages like

Apr 13 18:38:09 arch-64-lxqt-git dbus-daemon[862]: Activating service name='org.kde.KScreen'
Apr 13 18:38:09 arch-64-lxqt-git dbus-daemon[862]: Successfully activated service 'org.kde.KScreen'
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xrandr: Connected output 67 to CRTC 63
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xcb.helper: Detected XRandR 1.4
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xcb.helper: Event Base:  89
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xcb.helper: Event Error:  147
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen: Loading "XRandR" backend
Apr 13 18:38:09 arch-64-lxqt-git lxqt-config-monitor[3042]: Output:  "Virtual-0"
Apr 13 18:38:09 arch-64-lxqt-git lxqt-config-monitor[3042]: Output:  "Virtual-1"
Apr 13 18:38:09 arch-64-lxqt-git lxqt-config-monitor[3042]: Output:  "Virtual-2"
Apr 13 18:38:09 arch-64-lxqt-git lxqt-config-monitor[3042]: Output:  "Virtual-3"
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xrandr: XRandR::setConfig
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xrandr: Requested screen size is QSize(1024, 768)
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xrandr: Needed CRTCs:  1
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xrandr: Actions to perform:
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xrandr:         Primary Output: false
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xrandr:         Change Screen Size: false
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xrandr:         Disable outputs: false
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xrandr:         Change outputs: false
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xrandr:         Enable outputs: false
Apr 13 18:38:09 arch-64-lxqt-git kscreen_backend_launcher[3122]: kscreen.xrandr: XRandR::setConfig done!

The crashes reproducibly take place when the LXQt sessions gets finished before these configuration steps have been completed. This probably won't happen too frequently but may very well happen when e. g. an LXQt session was started incidentally.
Traces can be found on https://gist.github.com/pmattern/2c05d51d24400eb1ac03421623a21201

According to the logs it's KScreen to crash first, so the crash of lxqt-config-monitor is kind of secondary. Nonetheless a crash of the backend shouldn't necessarily trigger a crash of lxqt-config-monitor itself.
Attempts to figure out whether the crash of KScreen can be seen independently from LXQt failed. In KDE sessions the configuration stated above is finished long before any GUIs to terminate the session become accessible.

Seen running latest VCS checkouts of all LXQt components on up to date Arch Linux x86_64 running either in KVM/QEMU virtual machines or on hardware.

[selairi]

In KDE sessions the configuration stated above is finished long before any GUIs to terminate the session become accessible.

lxqt-config-monitor waits until all screen mode settings are ready. I have found in Ubuntu 15.10 that xrandr command doesn't show all modes at session start. It could be a X11 bug.

Nonetheless a crash of the backend shouldn't necessarily trigger a crash of lxqt-config-monitor itself.

I would try to catch the backend crash.

[pmattern]

In KDE sessions the configuration stated above is finished long before any GUIs to terminate the session become accessible.

lxqt-config-monitor waits until all screen mode settings are ready. I have found in Ubuntu 15.10 that xrandr command doesn't show all modes at session start. It could be a X11 bug.

Cannot see a correlation between these two statements.
Mine about KDE was just intended to explain why I failed to provoke the crash of the KScreen backend in KDE sessions - the GUIs to terminate these sessions simply come up too late, exactly speaking when all the configuration work is completed, and I don't know how to eventually terminate the session from a virtual terminal or an SSH session.

Nonetheless a crash of the backend shouldn't necessarily trigger a crash of lxqt-config-monitor itself.

I would try to catch the backend crash.

Not sure whether I got your answer right here. But the crash of KScreen itself is already comprised in the gist stated above.

[selairi]

Sorry. Perhaps I have misunderstood.

It is a fail in libkscreen. Output of kscreen_backend_launcher from Github Gist shows:

#2  0x00007ff963392f41 in QMessageLogger::fatal(char const*, ...) const () from /usr/lib/libQt5Core.so.5
#3  0x00007ff959e1fc10 in QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) 

I looks like that X11 connection is lost by kscreen_backend_launcher (maybe, X11 session is closed) and kscreen_backend_launcher send a QMessageLogger. Maybe, kscreen_backend_launcher should send a final DBus message.

[selairi]

I have opened monitor-fast-settings branch. lxqt-config-monitor doesn't wait until monitor modes are loaded. It should avoid KScreen cash. @pmattern could you be so kind as test it?

Thanks

[pmattern]

Running a2d7cde neither the crash of lxqt-config-monitor nor the one of the KScreen backend can be seen any longer.

[pmattern]

@selairi
Commit 41909ec of branch monitor-fast-settings is fixing the issue. Could you open a PR to get it into current master so that others can have their say, too, and we can get it merged the usual way?

[palinek]

Commit 41909ec of branch monitor-fast-settings is fixing the issue

The usage of QThread::sleep() is aparently wrong in such case (blocking the main/UI thread). If the delay is realy necessary, using of QTimer will probably be a better choice.