Unity8 crashes on suspend/standby with SIGSEGV in Screen::makeCurrent (./src/platforms/mirserver/screen.cpp:406)

[errors.ubuntu.com bug bridge]

The Ubuntu Error Tracker has been receiving reports about a problem regarding unity8. This problem was most recently seen with version 8.11+15.04.20151130.1-0ubuntu1, the problem page at https://errors.ubuntu.com/problem/6cee045a96ab5c9a03847aeb290f4860eea1034d contains more details.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Christopher Townsend (townsend)]

Bug #1654581 was duped to this one, but I will say that the crash has become much more prevalent, like nearly 100% reproducible after the last qtmir release.

[Christopher Townsend (townsend)]

This is the easiest way to reproduce for me:

- Unity 8 desktop session, either X+O or Zesty
- Create a Libertine container and install an app in it such as Firefox.
- Start the X app.
- Wait ~30 minutes, ie, leave the system alone.

Xmir seems to exacerbate the issue, but I have observed the crash without Xmir running.

[Christopher Townsend (townsend)]

Some more data points...

I disabled the screen blanking, but that made no difference.

But with the screen not blanked, I started an X app through Xmir and left U8 idle and observed at almost exactly 10 minutes of idle time, U8 crashed. This is what was in unity8.log at the time of the crash:

[2017-01-10 15:09:10.552229] mirserver: New display configuration:
[2017-01-10 15:09:10.552346] mirserver: Output 36: LVDS connected, used
[2017-01-10 15:09:10.552434] mirserver: Physical size 13,0" 290x160mm
[2017-01-10 15:09:10.552493] mirserver: Current mode 1366x768 60,00Hz
[2017-01-10 15:09:10.552549] mirserver: Preferred mode 1366x768 60,00Hz
[2017-01-10 15:09:10.552594] mirserver: Logical position +0+0
[2017-01-10 15:09:10.552676] mirserver: Output 43: VGA disconnected
[2017-01-10 15:09:10.552739] mirserver: Output 46: HDMI-A disconnected
[2017-01-10 15:09:10.552799] mirserver: Output 51: DisplayPort disconnected
[2017-01-10:15:09:10.553] qtmir.screens: QtCompositor::stop
[2017-01-10:15:09:10.554] qtmir.screens: ScreensModel::onCompositorStopping
[2017-01-10:15:09:10.554] qtmir.screens: ScreenWindow::setExposed 0x1c1e510 false 0x7f4ed824f020
[2017-01-10:15:09:10.581] qtmir.screens: ScreensModel::update
[2017-01-10:15:09:10.582] qtmir.screens: Screen::setMirDisplayBuffer Screen(0x7f4ed824f010) 0x7f4ed815cb40 0x7f4ed815cc90
[2017-01-10:15:09:10.582] qtmir.screens: =======================================
[2017-01-10:15:09:10.582] qtmir.screens: Screen(0x7f4ed824f010) - id: 36 geometry: QRect(0,0 1366x768) window: 0x1c1e510 type: "LVDS" scale: 1
[2017-01-10:15:09:10.582] qtmir.screens: =======================================
[2017-01-10:15:09:10.587] qtmir.screens: QtCompositor::start
[2017-01-10:15:09:10.587] qtmir.screens: ScreensModel::onCompositorStarting
[2017-01-10:15:09:10.587] qtmir.screens: ScreensModel::update
[2017-01-10:15:09:10.587] qtmir.screens: =======================================
[2017-01-10:15:09:10.587] qtmir.screens: Screen(0x7f4ed824f010) - id: 36 geometry: QRect(0,0 1366x768) window: 0x1c1e510 type: "LVDS" scale: 1
[2017-01-10:15:09:10.587] qtmir.screens: =======================================
[2017-01-10:15:09:10.587] qtmir.screens: ScreenWindow::setExposed 0x1c1e510 true 0x7f4ed824f020
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::system_error> >'
  what(): Nested Mir Display Error: Failed to update EGL surface: EGL_BAD_CONTEXT (0x3006)

[Gerry Boland (gerboland)]

I'm failing to reproduce this unfortunately. I'm also failing to create a libertine container. It was failing due to bug 1653973, so I installed silo 2341, but now it fails with:

Failed to download http://images.linuxcontainers.org//meta/1.0/index-user
LxcContainer.py:254: ERROR: create_libertine_container(): Failed to create container
libertine-container-manager:94: ERROR: create(): Failed to create container

This is odd, as networking is fine, and I can wget that URL successfully.

I've left my AMD laptop running with unity8 for hours yesterday, and no crash.

Can you paste more of that unity8.log please? From the output, it indicates that the physical display state changed somehow, or at least Mir thinks it did. Disabling screen blanking was a good idea, but are you sure it worked? How did you try it?

Also, what GPU have you got?

[Daniel van Vugt (vanvugt)]

You might find it useful to look through stack traces from other users:

https://errors.ubuntu.com/problem/6cee045a96ab5c9a03847aeb290f4860eea1034d

[Gerry Boland (gerboland)]

Yeah I figured it out. Non rootless (rooted!) XMir wants to decide the display power state (DPMS). Unity8/QtMir never had to deal with clients doing that before.

Longer term Unity8 should filter such requests as it's quite rude for an app to be able to turn off your display on you, but I've a branch up to at least not crash.

I've more work to do on this though, as waking up the display isn't working with that branch. To be continued

[Daniel van Vugt (vanvugt)]

Yeah, sorry I was meaning to tell you but never caught you on IRC... I noticed Xmir does modify the display config, but only to implement DPMS. That's legacy code from the days when Xmir was full screen. Although full screen mode is also the default mode. So I'm wondering if we need to make the behaviour conditional rather than delete the feature. It should be disabled in windowed and rootless modes...

It is actually valid for apps to be able to change the power mode of the display. mirout in Mir 0.26.0 has such an option. But I agree it's bad for apps to do it unexpectedly.

[Gerry Boland (gerboland)]

> It is actually valid for apps to be able to change the power mode
> of the display. mirout in Mir 0.26.0 has such an option. But I agree
> it's bad for apps to do it unexpectedly

@vanvugt can you share examples of times when this is valid? I'm of the opinion display on/off/suspend should be solely the shell's decision.

[Daniel van Vugt (vanvugt)]

I mean that historically it's always been possible, and sometimes useful, to be able to turn the screen off immediately on the command line (xset dpms ...).

It's not a major requirement, but a rare one. I can't even remember what my use case was for it in the past. In the case of 'mirout', I only added power commands for testing. I don't think anyone will complain in a hurry if no command line exists for changing the power mode.

As for Xmir turning the display off, that's just legacy code from before I adopted the project. I completely agree Xmir should not be changing power modes for Unity8.

[Daniel van Vugt (vanvugt)]

Oh, the use case for Unity7 is that Unity7 is buggy and randomly forgets to turn the screen off :)

[Gerry Boland (gerboland)]

Ok, rather marginal use-cases then :)

At least Mir allows this kind of request can be filtered by Unity8 in future, to prevent this kind of thing being abused. Perhaps need a system so that privileged clients can do this if they need.

[Daniel van Vugt (vanvugt)]

I have now prevented Xmir from turning the physical display off under Unity8:

https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/commit/?id=9a508dc77fd68f8ba321e82ed0d7c36df1ddf745

However it appears Xmir will still blank the Xmir window to black. Sounds like we need to launch Xmir with additional options to prevent that...

-p # screen-saver pattern duration (minutes)
-s # screen-saver timeout (minutes)
v video blanking for screen-saver
-v screen-saver without video blanking

[Michał Sawicz (saviq)]

There definitely are usecases for applications requesting display power changes, but yes they need to be filtered/mangled by the shell, and only applied when the requesting app, and session, are in focus.

Whether that should be a privileged operation, I'm not sure. As long as the user can easily escape it (Alt+Tab, power button etc.), I don't think we need to protect this.

[Daniel van Vugt (vanvugt)]

Fortunately that's already the case. An app in Unity8 is always asking Unity8 to ask USC to turn the screen off. Unity8 already has the option of rejecting it, in theory.

[Daniel van Vugt (vanvugt)]

And furthermore:

https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/commit/?id=8a53ab14880167946e805d3c16bab167fbb03683

[Launchpad Janitor (janitor)]

This bug was fixed in the package qtmir - 0.5.1+17.04.20170215.1-0ubuntu1

---------------
qtmir (0.5.1+17.04.20170215.1-0ubuntu1) zesty; urgency=medium

  [ Michał Sawicz ]
  * We're at provides 26 already (LP: #1662608)

  [ Alan Griffiths ]
  * Identify the code that depends directly on mirserver-dev headers

  [ Albert Astals Cid ]
  * Check we provide the same unity-application-impl that we require

  [ Daniel d'Andrada ]
  * Resolve mir cursor names using mir symbols instead of plain strings
    (LP: #1662827)

  [ Gerry Boland ]
  * ScreenModel: Only expose windows on displays that are turned on (LP:
    #1521403, #1638611, #1656250)
  * Restore lost LTTng tracepoints, and delete unused ones (LP:
    #1658084)

  [ Nick Dedekind ]
  * Added Extended Display Information Data (EDID) parsing.

  [ Alan Griffiths, Nick Dedekind ]
  * Iteration 0 of miral::PersistDisplayConfig. This does nothing yet
    (and breaks nothing in the process). This MP creates a place (miral-
    prototypes) to build prototype miral features and sketches out what
    will need to be implemented for PersistDisplayConfig. (LP: #1644189)

 -- Michał Sawicz <email address hidden> Wed, 15 Feb 2017 13:23:17 +0000

[Daniel van Vugt (vanvugt)]

Fixed in:
xorg-server (2:1.19.3-1ubuntu1) zesty; urgency=medium