Created attachment 1210026 [details]
File: backtrace

Created attachment 1210027 [details]
File: cgroup

Created attachment 1210028 [details]
File: core_backtrace

Created attachment 1210029 [details]
File: dso_list

Created attachment 1210030 [details]
File: environ

Created attachment 1210031 [details]
File: exploitable

Created attachment 1210032 [details]
File: limits

Created attachment 1210033 [details]
File: maps

Created attachment 1210034 [details]
File: mountinfo

Created attachment 1210035 [details]
File: namespaces

Created attachment 1210036 [details]
File: open_fds

Created attachment 1210037 [details]
File: proc_pid_status

Created attachment 1210038 [details]
File: var_log_messages

Similar problem has been detected:

The crash happens multiple times per day, unable to pin down what triggers it. Might have to do with firefox, but that is a hunch.

reporter:       libreport-2.8.0
backtrace_rating: 4
cmdline:        /usr/libexec/Xorg -background none :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt1 -novtswitch
crash_function: sna_set_cursor_position
executable:     /usr/libexec/Xorg
global_pid:     23902
kernel:         4.8.3-300.fc25.x86_64
package:        xorg-x11-server-Xorg-1.19.0-0.2.20160929.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         Xorg killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            0

Is there any way in which I can assist fixing this bug? My Xorg crashes multiple times per day (last three hours seven times) on a very unpredictable manner.

(In reply to Arjen Heidinga from comment #15)
> Is there any way in which I can assist fixing this bug? My Xorg crashes
> multiple times per day (last three hours seven times) on a very
> unpredictable manner.

Not a fix, but you can try doing:

sudo rpm -e xorg-x11-drivers xorg-x11-drv-intel

Then Xorg will fallback to the modesetting driver, which generally is more stable. We plan to make the modesetting driver the default for any recent intel hardware starting with F26, given the stability issues with the intel driver.

I encountered this again today (again in conjunction with bug 1384508). You can probably discern this from one of the attachments I uploaded on one of the bugs from abrt, but I *think* this happens when firefox has focus, and I'm moving the mouse pointer. I'm not sure if that info helps or not.

I'll try the change that Hans suggests in comment #16, and see if it's more stable for me.

Similar problem has been detected:

Thinkpad Yoga S1: Was working in Xournal, with the wacom stylus, in tablet mode, screen rotated left. 

reporter:       libreport-2.8.0
backtrace_rating: 4
cmdline:        /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3
crash_function: sna_set_cursor_position
executable:     /usr/libexec/Xorg
global_pid:     19721
kernel:         4.8.8-300.fc25.x86_64
package:        xorg-x11-server-Xorg-1.19.0-1.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         Xorg killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

I also hit this today.  :-(

(In reply to Brian J. Murrell from comment #19)
> I also hit this today.  :-(

Could be a an "intel" driver bug, have you tried using the modesetting driver as suggested by Hans in comment 16 ?

I use the modesetting driver since then indied. It is stable, but have alot of artifacts/flickering  on my screens. It also is significant slower than the intel driver, uses more power on my laptop.

Thinking of recent fixes upstream such as 

https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=0472b1f

or

https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=0111433

Moving to xorg-x11-drv-intel, considering the crash doesn't occur with the modesettings driver (comment 21), then I reckon it's a bug in xorg-x11-drv-intel.

I've prepared a *scratch* build [1] of a *test* package of xorg-x11-drv-intel which includes a couple of fixes from current git master for xf86-video-intel regarding the cursor with sna, you may want to try it to see if that helps:

  http://koji.fedoraproject.org/koji/taskinfo?taskID=16704057

[*] Note: Being a scratch build, it will automatically removed after some time.

Also running into this myself after upgrading to fc25 from fc24; using XFCE on a Lenovo T440s laptop. Happens several times a day now.

I'll give the above package a shot, thank you.

(In reply to Olivier Fourdan from comment #23)
> 
> I've prepared a *scratch* build [1] of a *test* package of
> xorg-x11-drv-intel which includes a couple of fixes from current git master

Didn't crashed for with this yet, looks fine here.

(In reply to Olivier Fourdan from comment #23)
> 
> I've prepared a *scratch* build [1] of a *test* package of
> xorg-x11-drv-intel which includes a couple of fixes from current git master
> for xf86-video-intel regarding the cursor with sna, you may want to try it
> to see if that helps:
> 
>   http://koji.fedoraproject.org/koji/taskinfo?taskID=16704057

Why does it bring in a bunch of 32-bit packages?


$ sudo dnf install xorg-x11-drv-intel-2.99.917-26.20160929.1test.fc25.x86_64.rpm
Last metadata expiration check: 1:14:30 ago on Sat Dec  3 12:45:57 2016.
Dependencies resolved.
================================================================================
 Package            Arch   Version                           Repository    Size
================================================================================
Installing:
 libXvMC            i686   1.0.10-1.fc25                     fedora        26 k
 xcb-util           i686   0.4.0-5.fc24                      fedora        20 k
 xorg-x11-drv-intel i686   2.99.917-26.20160929.fc25         fedora       713 k
Upgrading:
 xorg-x11-drv-intel x86_64 2.99.917-26.20160929.1test.fc25   @commandline 692 k

Transaction Summary
================================================================================
Install  3 Packages
Upgrade  1 Package

Total size: 1.4 M
Total download size: 760 k
Is this ok [y/N]:

(In reply to Brian J. Murrell from comment #26)
> 
> Why does it bring in a bunch of 32-bit packages?

That is just dnf being silly, you likely have something else installed depending on the exact version of 
xorg-x11-drv-intel you've installed (likely xorg-x11-drv-intel-devel or intel-gpu-tools) and dnf decides that it
can both satisfy that exact versioned dependency and install the newer x86_64 xorg-x11-drv-intel, by
installing the (old) i686 version to keep the exact versioned dependency satisfied.

Note this is not a dnf bug, dnf is just following dependencies and making sure they are satisfied, but the result is somewhat unexpected.

Ran this for a short time. Had one crash, and two full freezes in an hour.
Sorry to report. There was nothing in the system logs about the freeze, had to reboot hard.

Still crashing here as well, whether or I use XFCE or Cinnamon, using those beta packages.

Ditto to having a crash after installing the scratch build intel driver.

*** Bug 1404269 has been marked as a duplicate of this bug. ***

I experienced this crash twice within roughly an hour after I updated to the xorg-x11-drv-libinput-0.23.0-1.fc25, https://bodhi.fedoraproject.org/updates/FEDORA-2016-19134704e4. I don't remember experiencing this crash before.

I found this in the journal, IMO this (comm="InputThread") hints at input playing a role in the crash:

Dec 14 11:51:22 gibraltar audit[7003]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=7 subj=unconfined_u:unconfined_r:xserver_t:s0-s0:c0.c1023 pid=7003 comm="InputThread" exe="/usr/libexec/Xorg" sig=11

Nils, can I have a the full back trace from the journal please, thanks.

Peter, it seems there isn't a backtrace for Xorg in the journal, here's what I get in the journal that pertains directly to Xorg and not one of the other desktop processes that died out of solidarity:

Dec 14 10:58:26 gibraltar audit[3112]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:xserver_t:s0-s0:c0.c1023 pid=3112 comm="InputThread" exe="/usr/libexec/Xorg" sig=11
Dec 14 10:58:26 gibraltar abrt-hook-ccpp[6445]: Process 3092 (Xorg) of user 1000 killed by SIGSEGV - dumping core

I've created a backtrace from the coredump file which abrt thankfully saved and will attach it.

Created attachment 1232315 [details]
Backtrace of Xorg

(In reply to Nils Philippsen from comment #35)
> Peter, it seems there isn't a backtrace for Xorg in the journal, here's what
> I get in the journal that pertains directly to Xorg and not one of the other
> desktop processes that died out of solidarity

It might be because coredumpctl doesn't work in Fedora >=24 unless you downgrade SELinux from enforcing. Maybe that's what Peter did and expected the crash to show up in the journal.

Another piece of anecdata: I've used my laptop over the weekend without problems, now that I'm back in the office and it's attached to its docking station (using the mouse instead of the trackpad), it crashed on me again (roughly the same frequency, after about an hours time of use). I've downgraded to xorg-x11-drv-libinput-0.22.0-3.fc25.x86_64 to workaround it.

(In reply to Nils Philippsen from comment #38)
> Another piece of anecdata: I've used my laptop over the weekend without
> problems, now that I'm back in the office and it's attached to its docking
> station (using the mouse instead of the trackpad), it crashed on me again
> (roughly the same frequency, after about an hours time of use). I've
> downgraded to xorg-x11-drv-libinput-0.22.0-3.fc25.x86_64 to workaround it.

Downgrade *to* 0.22.0-3.fc25? That's the one I have now that appears to be causing me so much grief..

I see 0.23.0-1.fc25 is available, but I haven't yet installed it.

(In reply to Hans de Goede from comment #16)
> (In reply to Arjen Heidinga from comment #15)
> > Is there any way in which I can assist fixing this bug? My Xorg crashes
> > multiple times per day (last three hours seven times) on a very
> > unpredictable manner.
> 
> Not a fix, but you can try doing:
> 
> sudo rpm -e xorg-x11-drivers xorg-x11-drv-intel
> 
> Then Xorg will fallback to the modesetting driver, which generally is more
> stable. We plan to make the modesetting driver the default for any recent
> intel hardware starting with F26, given the stability issues with the intel
> driver.

I have the same issue,
unfortunately modesetting driver driver isn't stable in my case,
with it windows flicker crazily making system unusable (the same issues with Wayland witch uses modesetting).

I use thinkpad t440s in dock with 2 external display-port attached displays (total 3 displays including laptop's panel).
HW config:
i7-4600U/12Gb RAM/
00:02.0 0300: 8086:0a16 (rev 0b) (prog-if 00 [VGA controller])
	Subsystem: 17aa:220c
	Flags: bus master, fast devsel, latency 0, IRQ 46
	Memory at e0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at c0000000 (64-bit, prefetchable) [size=512M]
	I/O ports at 3000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915
	Kernel modules: i915

Meanwhile it crashed in a similar fashion with xorg-x11-drv-libinput-0.22.0-3.fc25.x86_64, too. I'm trying out Wayland again and so far it looks good to me (but nothing that helps debugging this issue obviously).

fwiw, I doubt this is a bug in a specific xorg-x11-drv-libinput version as such, you're most likely running into a race condition between the input thread and the main thread.

Adding Chris to CC as he's been the last to touch sna->cursor upstream
so he could look at backtrace in comment 36.

Same as Nils in comment 35, I see this in my journal when Xorg crashes:

Dec 22 15:38:53 pnickerson-fedora-t450s audit[7387]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=532 subj=unconfined_u:unconfined_r:xserver_t:s0-s0:c0.c1023 pid=7387 comm="InputThread" exe="/usr/libexec/Xorg" sig=11
Dec 22 15:38:53 pnickerson-fedora-t450s abrt-hook-ccpp[23892]: Process 7378 (Xorg) of user 1000 killed by SIGSEGV - dumping core

I have noticed that Xorg only crashes when I have my Lenovo ThinkPad T450s laptop at work, in its dock (ThinkPad Pro Dock), connected to two external monitors (one connected to dock, the other connected to laptop). And, I have my Logitech M325 mouse at work. I *think* that the Xorg crash only happens while I'm moving my mouse, but I'm not positive. I do keep the mouse receiver plugged in to USB all the time, even away from the office.

I have a Lenovo ThinkPad T440s and am experiencing this crash only when it is connected to the dock. I have two monitors connected to the dock, and am using a wired mouse and keyboard, which are connected to the dock.

The crashes seem very random to me, but only when during active use, it never crashed while the computer was idling.

Created attachment 1234896 [details]
Backtrace from my Xorg crash

Using gnome-abrt, I got the problem's data directory. In there, I ran the command below, ran the dnf commands it recommended, and ran it again.

gdb $(cat executable) -c coredump

On the gdm prompt, I ran all of these, to make sure all the info desired is captured.

(gdb) bt
(gdb) bt full
(gdb) info threads
(gdb) thread apply all bt
(gdb) thread apply all bt full

Expanding on Paul's and Gabriel's comments, my laptop is a Thinkpad T540p, I saw the crashes when it's connected to the dock which has two displays (one DVI, one DisplayPort) and one USB mouse attached. I seem to recall that they also happened when I used the mouse, but like Paul I'm not 100% sure on that.

it looks like adding
 Option "AccelMethod" "uxa"
to intel card config makes crashes go away but makes Chrome browser painfully slow.
Anyway it suggests that bug is in intel's driver SNA backend.

Olivier,

could you respin scratch build mentioned in comment 23 so it would be possible to try it out again and see where patched version would crash.

I'm seeing this with i3 on a Lattitude e7450, also observed only when docked - although I don't use it undocked enough to confidently attribute the issue to the dock. Xorg.0.log exits silently, there's nothing indicative of a crash after each event.  Uploads sent, open to testing.

To be clear this bug has absolutely nothing to do with docking.  My desktop PC is not even a laptop and therefore not even dockable and I see this at least once a day.

I'm also seeing this issue.
 - Thinkpad T440s
 - Xorg + Intel graphics - xorg-x11-drv-intel-2.99.917-26.20160929.fc25.x86_64
 - Fedora 25 - 4.8.15-300.fc25.x86_64
 

Like many of the others I'm running a dock with multiple monitors.
 - 1 - Laptop screen 1080p
 - 2 - Samsung HDMI - 1200p
 - 3 - Samsung DVI - 1200p rotated 90 degrees

I don't have this occur at home with my laptop directly connected to a 1200p monitor over VGA.

I haven't had this happen in quite a while now, but just noticing that Steven experiences it with a rotated monitor as part of his configuration, like me (although, different machine, different monitor, more monitors -- so there are more differences than similarities in our cases)

(In reply to Steven Ellis from comment #51)
> <snip>
>  - 3 - Samsung DVI - 1200p rotated 90 degrees

(In reply to Brian J. Murrell from comment #50)
> To be clear this bug has absolutely nothing to do with docking.  My desktop
> PC is not even a laptop and therefore not even dockable and I see this at
> least once a day.

Do you have a rotated display? It might not be the dock, but I do see it regularly with my rotated display setup.

(In reply to Debarshi Ray from comment #53)
> 
> Do you have a rotated display? It might not be the dock, but I do see it
> regularly with my rotated display setup.

Indeed, I do.  I have dual screens, one rotated and one not.

Seems we are homing in here on what is causing this.

I can confirm that issue happens to me also only when docked with two external monitors, where one of them is rotated. I am running thinkpad t440s and i3 session.

I also confirm that this only happens with triple-screen setup, with one rotated monitor.

This happens to me with a multimonitor setup with one screen rotated in portrait mode on a Lenovo ThinkPad W541 running Gnome 3.22 under X11.

My usual setup is also one rotated screen:

- ThinkPad X220
- Two Dell P2314H, one on the DisplayPort on the Dock, another on the DisplayPort on the laptop (that one rotated).

Oh, this is awesome. I am also rotated. I have a laptop screen at 1600x900, a horizontal display to the right of that at 1920x1080, and to the right of that vertical screen at 1080x1920. So, if there is a virtual display frame of some kind, it is sized at 4600x1920.

I will try unrotating my vertical display for two days, and report back with whether I got a crash without it rotated. I've been getting usually two crashes per work day, never less than one, so two days is a good test I think.

Here is upstream BZ for this issue

https://bugs.freedesktop.org/show_bug.cgi?id=99358

it could be better to report our findings there, once it's fixed upstream we'd backport it to fedora.

Confirming that I have a rotated monitor as well.

My setup in full:

Lenovo ThinkPad T440s
Fedora 25, 4.8.16-300.fc25.x86_64
Docked, with two external 23" ASUS LCD panels connected via DisplayPort->HDMI adapters; my right-most screen is rotated 90* clockwise, such that I have:

[Laptop 13"] [Desktop 23"] [Desktop
                            23"
                            Rotated]

I have been running in a "mirrored" mode for a while now where all three screens show the same exact output with no crashes. It's only when I try to engage my proper layout settings that things go to heck.

Of course, that sucks just a little bit.

I've also got a rotated screen when the issue occurs. I've not see it happen without a rotated display.

I unrotated my screen for a couple days, and the crash never occurred, so that's a workable if undesirable workaround.

My coworker theorizes this crash may have something to do with the live windows thumbnails used in the activities overview (super key) of GNOME. I think that I might have had a maximized window on my vertical monitor in the current workspace during each crash. Maybe the constant re-scanning of windows doesn't work well for tall windows?

I'll try to test that out next time I get a chance.

(In reply to Paul Nickerson from comment #66)
> My coworker theorizes this crash may have something to do with the live
> windows thumbnails used in the activities overview (super key) of GNOME.

I use Awesome WM, which does not have any thumbnails. And there the crash also occurs.

----

For the last days I have not used my rotated screen and there have been no crashes.

Upstream has two suggested patches in the bugzilla, here's a quick scratch build for testing:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17308524

I am terribly sorry to inform that I have had already two crashes within the last 20 minutes.

Created attachment 1241637 [details]
Backtrace from build of comment #68

(In reply to Arjen Heidinga from comment #69)
> I am terribly sorry to inform that I have had already two crashes within the
> last 20 minutes.

so far (2 days) I don't have crashes, but I've rebuild xorg-server myself + using current git HEAD of intel driver.
I'll let it run for a week before declaring that it works for me.

(In reply to Igor Mammedov from comment #71)
> (In reply to Arjen Heidinga from comment #69)
> > I am terribly sorry to inform that I have had already two crashes within the
> > last 20 minutes.
> 
> so far (2 days) I don't have crashes, but I've rebuild xorg-server myself +
> using current git HEAD of intel driver.
It's crashed on the 3rd day. :(

https://koji.fedoraproject.org/koji/taskinfo?taskID=17385289

One more patch added from upstream

Running for an hour now, looks promising (although this post will jinx it ;-) ).
I will continue testing.

Happened to me 3 times in three days and that's my 3 first days on Fedora.

same as everyone here, 3rd screen rotated.

xrandr output:

```
Screen 0: minimum 8 x 8, current 4920 x 1920, maximum 32767 x 32767
eDP1 connected primary 1920x1080+1920+840 (normal left inverted right x axis y axis) 340mm x 190mm
   1920x1080     60.01*+  40.00  
   1400x1050     59.98  
   1600x900      60.00  
   1280x1024     60.02  
   1280x960      60.00  
   1368x768      60.00  
   1280x720      60.00  
   1024x768      60.00  
   1024x576      60.00  
   960x540       60.00  
   800x600       60.32    56.25  
   864x486       60.00  
   640x480       59.94  
   720x405       60.00  
   640x360       60.00  
VGA1 connected 1080x1920+3840+0 left (normal left inverted right x axis y axis) 480mm x 270mm
   1920x1080     60.00*+
   1680x1050     59.95  
   1600x900      60.00  
   1280x1024     60.02  
   1440x900      59.89  
   1280x720      60.00  
   1024x768      60.00  
   800x600       60.32  
   640x480       59.94  
   720x400       70.08  
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
DP-1-1 disconnected (normal left inverted right x axis y axis)
DP-1-2 disconnected (normal left inverted right x axis y axis)
DP-1-3 connected 1920x1080+0+840 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080     60.00*+
   1680x1050     59.95  
   1600x900      60.00  
   1280x1024     60.02  
   1440x900      59.89  
   1280x720      60.00  
   1024x768      60.00  
   800x600       60.32  
   640x480       59.94  
   720x400       70.08  
  1920x1080 (0x67) 148.500MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.50KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  60.00Hz
  1680x1050 (0x68) 146.250MHz -HSync +VSync
        h: width  1680 start 1784 end 1960 total 2240 skew    0 clock  65.29KHz
        v: height 1050 start 1053 end 1059 total 1089           clock  59.95Hz
  1600x900 (0x69) 108.000MHz +HSync +VSync
        h: width  1600 start 1624 end 1704 total 1800 skew    0 clock  60.00KHz
        v: height  900 start  901 end  904 total 1000           clock  60.00Hz
  1280x1024 (0x6a) 108.000MHz +HSync +VSync
        h: width  1280 start 1328 end 1440 total 1688 skew    0 clock  63.98KHz
        v: height 1024 start 1025 end 1028 total 1066           clock  60.02Hz
  1440x900 (0x6b) 106.500MHz -HSync +VSync
        h: width  1440 start 1520 end 1672 total 1904 skew    0 clock  55.93KHz
        v: height  900 start  903 end  909 total  934           clock  59.89Hz
  1280x720 (0x6c) 74.250MHz +HSync +VSync
        h: width  1280 start 1390 end 1430 total 1650 skew    0 clock  45.00KHz
        v: height  720 start  725 end  730 total  750           clock  60.00Hz
  1024x768 (0x6d) 65.000MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock  48.36KHz
        v: height  768 start  771 end  777 total  806           clock  60.00Hz
  800x600 (0x6e) 40.000MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock  37.88KHz
        v: height  600 start  601 end  605 total  628           clock  60.32Hz
  640x480 (0x6f) 25.175MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock  31.47KHz
        v: height  480 start  490 end  492 total  525           clock  59.94Hz
  720x400 (0x70) 28.320MHz -HSync +VSync
        h: width   720 start  738 end  846 total  900 skew    0 clock  31.47KHz
        v: height  400 start  412 end  414 total  449           clock  70.08Hz
```

gnome-session crashed right after.
xorg-x11-server-Xorg-1.19.1-2.fc25

*** Bug 1397838 has been marked as a duplicate of this bug. ***

Running for more than a week stable now. I declare this fixed (for me) :)
Huray!

xorg-x11-server-1.19.1-3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-921eec0341

xorg-x11-server-1.19.1-3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-921eec0341

xorg-x11-server-1.19.1-3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.