After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 709009 - crash when monitor is turned off and on again
crash when monitor is turned off and on again
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
3.10.x
Other Linux
: Normal critical
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2013-09-28 23:42 UTC by Torsten Scholak
Modified: 2013-10-21 19:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
monitor-config: don't assert that at least one output is connected (1.49 KB, patch)
2013-10-15 18:13 UTC, Giovanni Campagna
committed Details | Review

Description Torsten Scholak 2013-09-28 23:42:23 UTC
Description of problem:
I am experiencing a fatal error when I turn the monitor off and back on again. I don't know whether it's the former or the latter that triggers the fault.
When the monitor is turned off and on at the login prompt, gdm is frozen. The mouse cursor is displayed properly, but I cannot click anywhere. I have to login as root in a terminal and restart gdm.
When the monitor is switched off and on again in a gnome session, I am greeted with the "oh snap" screen of death. I can click ok to get back to gdm, which lets me log in again without a restart. Sometimes I see various application windows floating around the "oh snap" message, ripped off their decorations and presented in legacy (motif? cde?) instead of the adwaita gui style.

How reproducible:
Always faults.

Steps to reproduce:
Be either in gdm's login screen or in a gnome session. Turn the monitor off. Turn it on again. Surprise.

Actual results:
Fatal error. gdm is frozen or the gnome-session ends abruptly.

Expected results:
Flawless continuation of operation.

Additional info:
I have tried the same in twm. No problem.
The issue manifested after upgrading to 3.10. 3.8.x was unaffected.
Comment 1 Torsten Scholak 2013-09-29 01:11:53 UTC
Here's a backtrace. The sigabrt is raised when I turn the monitor off. 

  • #0 __GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #1 __GI_abort
    at abort.c line 91
  • #2 _g_log_abort
    at /var/tmp/portage/dev-libs/glib-2.38.0/work/glib-2.38.0/glib/gmessages.c line 255
  • #3 g_assertion_message
  • #4 g_assertion_message_expr
    at /var/tmp/portage/dev-libs/glib-2.38.0/work/glib-2.38.0/glib/gtestutils.c line 2293
  • #5 find_primary_output
    at core/monitor-config.c line 1016
  • #6 make_default_config
    at core/monitor-config.c line 1147
  • #7 meta_monitor_config_make_default
    at core/monitor-config.c line 1234
  • #8 meta_monitor_manager_constructed
    at core/monitor.c line 504
  • #9 g_object_new_internal
    at /var/tmp/portage/dev-libs/glib-2.38.0/work/glib-2.38.0/gobject/gobject.c line 1785
  • #10 g_object_newv
    at /var/tmp/portage/dev-libs/glib-2.38.0/work/glib-2.38.0/gobject/gobject.c line 1890
  • #11 g_object_new
    at /var/tmp/portage/dev-libs/glib-2.38.0/work/glib-2.38.0/gobject/gobject.c line 1556
  • #12 meta_monitor_manager_new
    at core/monitor.c line 489
  • #13 meta_monitor_manager_initialize
    at core/monitor.c line 1405
  • #14 meta_screen_new
    at core/screen.c line 676
  • #15 meta_display_open
    at core/display.c line 910
  • #16 meta_run
    at core/main.c line 553
  • #17 main
    at main.c line 439

Comment 2 Owen Taylor 2013-09-30 15:24:41 UTC
I get this crash if I *unplug* the only connected monitor

In general, the DDC standard used to provide information about connected monitors is supposed to report information even when a monitor isn't turned on - however, we clearly need to be robust against this:

 - In case of unusual monitors
 - If the user knocks out their monitor cable
 - If there is a KVM switch that doesn't pass DDC information to disconnected outputs

Etc. Having no connected outputs is a state we need to guard against.

I'm not immediately sure how to do this however - maybe we should create a dummy output that is the size of the current root window and return that from meta_monitor_manager_xrandr_read_current()?

I don't think we want to actually return information out of the monitor manager about disconnected outputs - all our abstractions are built around the idea that an output is a *connected* output, and reflects a monitor with a definite display size, not a connector sitting empty.
Comment 3 Jasper St. Pierre (not reading bugmail) 2013-09-30 15:48:25 UTC
DisplayPort (and perhaps other connection technologies) does not differentiate between unplug and turn off, unfortunately, so that might be what the reporter is seeing.
Comment 4 Torsten Scholak 2013-09-30 15:51:56 UTC
The monitor is connected via DisplayPort, indeed.
Comment 5 Giovanni Campagna 2013-10-15 18:13:46 UTC
Created attachment 257381 [details] [review]
monitor-config: don't assert that at least one output is connected

Apparently some connector technologies don't distinguish between
on and off, and there might be valid use cases for running without
any connected monitor.
In that case, just avoid any configuration at all.
Comment 6 Jasper St. Pierre (not reading bugmail) 2013-10-15 18:24:11 UTC
Review of attachment 257381 [details] [review]:

Where are you removing the assert?
Comment 7 Giovanni Campagna 2013-10-15 18:25:41 UTC
(In reply to comment #6)
> Review of attachment 257381 [details] [review]:
> 
> Where are you removing the assert?

I'm not removing the assert, I'm removing all ways to trigger it.
Comment 8 Jasper St. Pierre (not reading bugmail) 2013-10-15 18:26:57 UTC
Review of attachment 257381 [details] [review]:

A better commit message would be appreciated, then.
Comment 9 Giovanni Campagna 2013-10-15 19:27:18 UTC
Pushed
Comment 10 Giovanni Campagna 2013-10-21 19:19:19 UTC
*** Bug 710239 has been marked as a duplicate of this bug. ***