Hide Forgot
Created attachment 1223510 [details] backtrace #1 (cut & paste ) Description of problem: Freshly installed brand-new F25 Workstation Live, 64 bit (previously F24 without problems). All available patches. I run "startx" from text console with minimal .Xclients (gnome-settings-daemon and xterm). When I start any GNOME application (eg, gnome-terminal, gnome-calculator) or other complex software with GUI, Xorg crashes. Unfortunately, the segfault/backtrace goes directly to the console (ignoring any output redirection). Logs do not show obvious errors. When booting with kernel option nouveau.noaccel=1 (acceleration disabled), Xorg does not crash. But this limits graphics capabilities significantly. Never had to use noaccel before, always worked fine (eg, latest F24 with xorg-x11-server 1.18 packages). Version-Release number of selected component (if applicable): xorg-x11-server-(common|Xorg|Xwayland)-1.19.0-0.8.rc2.fc25.x86_64 was installed after installation/patches. When Xorg crashed all the time, I've upgraded to 1.19.0-1.fc25.x86_64 from "testing", but it didn't get any better (changelog mentions lots of Xwayland fixes but nothing significant for Xorg). How reproducible: Always. Steps to Reproduce: 1. Create minimal .Xclients #!/bin/sh /usr/libexec/gnome-settings-daemon & sleep 2 xterm 2. startx (Xorg starts, xterm window opens) 3. gnome-terminal (start from xterm) Actual results: The initial (still empty) window of gnome-terminal shows up for milliseconds but then Xorg crashes dumping its backtrace directly to text console. Expected results: Xorg does not crash. Additional info: Appended are two backtraces (cut & paste from text console, end is missing, only what fits on screen) and the standard Xorg.0.log (doesn't show any obvious problems to me). I know this is not much information. Please let me know how I can provide better one that is more useful for debugging. Maybe there's also a problem with nouveau (slightly different version in F24 and F25). However, Xorg is the binary that crashes (so I filed the bug report here). As you can imagine, the computer (desktop PC) is pretty much useless right now without a working Xorg server. If there's anything I can try out, just let me know. I'm all yours. :-)
Created attachment 1223511 [details] backtrace #2 (cut & paste)
Created attachment 1223512 [details] Xorg.0.log (~/.local/share/xorg)
Unfortunately, the test case wasn't 100% clean. A custom font configuration (~/.config/fontconfig/fonts.conf) existed. At this point I wasn't aware that the crash was caused by those very font settings. New steps to Reproduce: 1. Create fresh user account (no pre-existing config :-) with this minimal .Xclients #!/bin/sh /usr/libexec/gnome-settings-daemon & sleep 2 xterm 2. startx (Xorg starts, xterm window opens) 3. In xterm, enter "gsettings set org.gnome.settings-daemon.plugins.xsettings antialiasing none" to turn of font anti-aliasing (the default is "grayscale", meaning anti-aliasing is enabled). Or use "gnome-tweak-tool", same result. 4. Quit X session (type "exit" in xterm). 5. startx (Xorg starts, xterm window opens - same as before) 6. gnome-terminal (start from xterm) (BOOM! Xorg crashes, user is put back to Linux text console. gnome-terminal is just the trigger for the crash, other GNOME apps like gnome-calculator or gnome-control-center do the same.) In fact, that tiny detail (existing font configuration) was the key to the real problem. Now it may be the same issue as described in bug #1400374 although this here is more "pure" because it has less GNOME stuff involved. This bug ticket describes a simplified test case. Of course, a single xterm is not my real-life setup. I am using font anti-aliasing by default, and my font configuration then turns it off (!) for specific fonts. This causes Xorg to crash as well, but that configuration is a little bit more complicated. As described in bug #1400374 the crash depends on graphics hardware/driver. I cannot reproduce it with an identical setup on Intel i915 graphics. Crash happens here with Nvidia/nouveau, and as said, no crash with NoAccel=1. It worked all fine with Fedora 24. I'm very sorry for my incomplete initial bug report.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. 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 25 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.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.