Bug 1004045 - Xorg crashes with segfault when disabling nouveau optimus output with xrandr
Xorg crashes with segfault when disabling nouveau optimus output with xrandr
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Depends On:
  Show dependency treegraph
Reported: 2013-09-03 15:07 EDT by Pasi Karkkainen
Modified: 2015-02-17 12:02 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-02-17 12:02:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.0.log with the segfault backtrace (52.26 KB, text/plain)
2013-09-03 15:10 EDT, Pasi Karkkainen
no flags Details
differences in ~/.kde from a normal install, compared to one that segfaulted every time. (4.27 KB, text/plain)
2013-11-15 01:11 EST, Nick
no flags Details

  None (edit)
Description Pasi Karkkainen 2013-09-03 15:07:25 EDT
Description of problem:

Xorg segfaults when running "xrandr --output DP-2 --off" to disable an output on *nouveau* card. Backtrace in Xorg.0.log has Intel strings in it, but the crash is triggered by disabling an output on nouveau/optimus adapter.

I'm using Fedora 19 on Lenovo T430 laptop in Optimus mode (Intel Ivy Bridge + Nouveau GF108):

Version-Release number of selected component (if applicable):
Fedora 19 with latest updates installed.

How reproducible:
Very often.

Steps to Reproduce:
1. Enable Optimus in BIOS on Lenovo T430 laptop.
2. Connect laptop to docking station.
3. Connect external DVI monitor to docking station DVI port.
4. Start Fedora 19, login to (mate) desktop.
5. Start a terminal and run "xrandr --output DP-2 --off".

Actual results:
Xorg crashes with segfault/backtrace.

Expected results:
Xorg doesn't crash and nouveau output (DVI monitor) gets disabled.

Additional info:

[   138.763] reporting 5 7 17 134
[   139.048] have a master to look out for
[   139.048] (EE) 
[   139.048] (EE) Backtrace:
[   139.052] (EE) 0: /usr/bin/X (OsLookupColor+0x129) [0x46ee59]
[   139.052] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x36f2e0ef9f]
[   139.053] (EE) 2: /lib64/libdrm_intel.so.1 (drm_intel_bufmgr_fake_init+0xe3b) [0x7f2bd9ff2f3b]
[   139.054] (EE) 3: /lib64/libdrm_intel.so.1 (drm_intel_bufmgr_fake_init+0x2924) [0x7f2bd9ff6134]
[   139.055] (EE) 4: /usr/lib64/xorg/modules/drivers/intel_drv.so (_init+0x9f22) [0x7f2bda22cf12]
[   139.055] (EE) 5: /usr/lib64/xorg/modules/drivers/intel_drv.so (_init+0x6075) [0x7f2bda225285]
[   139.056] (EE) 6: /usr/bin/X (xf86PruneDuplicateModes+0x1df7) [0x4c84e7]
[   139.056] (EE) 7: /usr/bin/X (RRCrtcSet+0x589) [0x502b39]
[   139.056] (EE) 8: /usr/bin/X (ProcRRSetCrtcConfig+0x3d9) [0x503c99]
[   139.056] (EE) 9: /usr/bin/X (SendErrorToClient+0x3f7) [0x436fe7]
[   139.057] (EE) 10: /usr/bin/X (_init+0x3aaa) [0x429b8a]
[   139.058] (EE) 11: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x36f2621b75]
[   139.058] (EE) 12: /usr/bin/X (_start+0x29) [0x4267f1]
[   139.059] (EE) 13: ? (?+0x29) [0x29]
[   139.059] (EE) 
[   139.059] (EE) Segmentation fault at address 0x8
[   139.059] (EE) 
Fatal server error:
[   139.059] (EE) Caught signal 11 (Segmentation fault). Server aborting
[   139.059] (EE) 
[   139.059] (EE) 
Please consult the Fedora Project support 
         at http://wiki.x.org
 for help. 
[   139.059] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[   139.059] (EE) 
[   139.060] (II) AIGLX: Suspending AIGLX clients for VT switch
[   139.543] (EE) Server terminated with error (1). Closing log file.
Comment 1 Pasi Karkkainen 2013-09-03 15:10:24 EDT
Created attachment 793335 [details]
Xorg.0.log with the segfault backtrace
Comment 2 Pasi Karkkainen 2013-09-23 11:20:45 EDT
This crash is probably related to:

"segfault in OsLookupColor":
Comment 3 Pasi Karkkainen 2013-10-01 15:55:53 EDT
I also filed upstream bugreport to:

"[uxa optimus] Xorg server crashes with segfault when disabling nouveau optimus output with xrandr":
Comment 4 Nick 2013-10-02 01:07:24 EDT
I can confirm this bug also happens on the Lenovo T420 with NVidia Optimus (NVS4100), running under the default Nouveau driver.  It is extremely easy to reproduce, as OP mentioned.

In my case, I'm using KDE4 and the "Display Configuration" front-end to XRandR.  Simply disabling the external display segfaults X, and it goes back to the KDM greeter, completely eradicating my existing session.

It also occurs even with the built-in DisplayPort adapter when I'm not docked.  So the issue isn't solely related to the docking station.

My workaround: log out, undock, alt-E to restart the X server.  Then log back in, un-docked, and suspend the laptop prior to stuffing it in a bag for travel.

Side note: at least the digital ports work now, and for that, I am grateful!  I used to have to use my VGA ports only in F17.  This particular fault has been the only post-install flaw I've found in Fedora 19 on the T420.
Comment 5 Nick 2013-10-02 01:08:57 EDT
Correction, the card is an NVidia Quadro NVS4200.  The Intel card is the integrated card on the i7-2640M processor.
Comment 6 Pasi Karkkainen 2013-10-04 17:52:07 EDT
With the latest Fedora 19 updates, as of today, I can't reproduce the crash anymore. It seems to work OK now.

Versions I have now: Linux kernel 3.11.2-201.fc19.x86_64, xorg-x11-server-Xorg-1.14.3-1.fc19.x86_64, xorg-x11-drv-intel-2.21.12-2.fc19.x86_64, xorg-x11-drv-nouveau-1.0.9-1.fc19.x86_64.
Comment 7 Nick 2013-10-05 17:06:32 EDT
I still can.  Here's today's backtrace.  Note that I have the same kernel, intel and nouveau drivers, and Xorg server as you.

[    43.715] (EE) 
[    43.715] (EE) Backtrace:
[    43.720] (EE) 0: /usr/bin/X (OsLookupColor+0x129) [0x46ee59]
[    43.720] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x3fa720ef9f]
[    43.721] (EE) 2: /lib64/libdrm_intel.so.1 (drm_intel_bufmgr_fake_init+0xe3b) [0x7fcf14757f3b]
[    43.722] (EE) 3: /lib64/libdrm_intel.so.1 (drm_intel_bufmgr_fake_init+0x2924) [0x7fcf1475b134]
[    43.724] (EE) 4: /usr/lib64/xorg/modules/drivers/intel_drv.so (_init+0x9f22) [0x7fcf14991f12]
[    43.725] (EE) 5: /usr/lib64/xorg/modules/drivers/intel_drv.so (_init+0x6075) [0x7fcf1498a285]
[    43.727] (EE) 6: /usr/bin/X (xf86PruneDuplicateModes+0x1df7) [0x4c84e7]
[    43.727] (EE) 7: /usr/bin/X (RRCrtcSet+0x589) [0x502b39]
[    43.727] (EE) 8: /usr/bin/X (ProcRRSetCrtcConfig+0x3d9) [0x503c99]
[    43.727] (EE) 9: /usr/bin/X (SendErrorToClient+0x3f7) [0x436fe7]
[    43.728] (EE) 10: /usr/bin/X (_init+0x3aaa) [0x429b8a]
[    43.730] (EE) 11: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x3fa6a21b75]
[    43.730] (EE) 12: /usr/bin/X (_start+0x29) [0x4267f1]
[    43.731] (EE) 13: ? (?+0x29) [0x29]
[    43.731] (EE) 
[    43.731] (EE) Segmentation fault at address 0x8
[    43.731] (EE) 
Fatal server error:
[    43.731] (EE) Caught signal 11 (Segmentation fault). Server aborting
Comment 8 Nick 2013-10-05 17:10:32 EDT
So, on a lark, I figured it might be related to my ~/.kde data somehow.  Made a new user, tried to disable the output, and it was fine?  So perhaps this bug *can* be marked closed..  Going to try a fresh ~/.kde and see what happens.
Comment 9 Nick 2013-11-15 01:10:40 EST
Busy with work, and didn't have time to really investigate this bug deeply.  

So, at this time, the bug is very much reproducible.  If I want to segfault X, here's what I do:

1) boot laptop
2) dock, or plug into displayport, an external monitor.
3) login via KDM to KDE.
4) open the display manager
5) undock or disconnect the monitor.
6) untick the check box for the external monitor.
7) click apply or ok
8) segfault.

I tried this all on a fresh new user that didn't have all of my crufty old KDE configs from back in the KDE 4.0 days.  

I had trouble reproducing the segfault for a bit, but then managed to change the monitor offset, and it crashed.  I took a snapshot of my .kde folder before and after the segfault, and attached the diff.  The key for me, was that once I got it to segfault once, no matter what I did inside the Display Manager too, it would segfault once I made a change and exited.

That lead me to believe it was somehow related to a file on-disk.

The diff showed me a file, ~/.kde/share/apps/kscreen/<randomhashvalue>, and the significant difference was that the starting Y coordinate for that file was non-zero.  As long as that was zero, it didn't seem to crash.  (or so I thought.)  To test that, I marked the file immutable, and then tried to reproduce the crash.  Sadly, with a little effort, I was able to do so.

Perhaps that file is a red herring, I don't know.  But I do know that once the bug is triggered once, its significantly easier to trigger it a second time.
Comment 10 Nick 2013-11-15 01:11:34 EST
Created attachment 824318 [details]
differences in ~/.kde from a normal install, compared to one that segfaulted every time.
Comment 11 Nick 2013-11-15 01:14:58 EST
The above commentary was with my laptop running the following:


There's a bunch of updates to KDE, so I'm updating and will try to reproduce again.
Comment 12 Fedora End Of Life 2015-01-09 14:42:39 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 13 Fedora End Of Life 2015-02-17 12:02:46 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.