Created attachment 117847 [details]
xorg server debugging information
... when switching a video player to full screen mode.
Linux kernel 4.1.5
Google Chrome 44.0.2403.157
Video used: https://www.youtube.com/watch?v=U1AnXRj-oBc
5a9a3e73a9252cffbaf5f361e98c096095725a64 is the first bad commit
Author: Chris Wilson <firstname.lastname@example.org>
Date: Tue Aug 11 10:48:48 2015 +0100
sna/dri2: Keep the most-recent back buffer cache when reaping on idle
When the client misses a swap, we consider it idle and unlikely to swap
again for a while. We try to take advantage of that and remove the old
back buffers. But it is likely to swap again and so having some of that
cache around would be advantageous.
Signed-off-by: Chris Wilson <email@example.com>
Created attachment 117848 [details]
Curious. The intent there is to do less work! Does TearFree affect the crash?
Happens also without Tearfree, but SIGSEGV is more difficult to reproduce, I think.
If you revert both 656c0a6946f3bd99ee89486d34bcde8d09af2307 and 5a9a3e73a9252cffbaf5f361e98c096095725a64 on top of master?
Created attachment 117856 [details]
No more SIGSEGV's, but sometimes, when exiting full screen, Chrome's window is not repainted correctly (but that's probably another issue)
Haven't spotted the culprit yet, pretty sure it has to be memory corruption. Does compiling xf86-video-intel with ./configure --enable-debug reveal anything?
I'm really, really confused right now. I'm no longer able to reproduce this crash. It is possible that it was triggered by a buggy YT html5 video player (fixed in meantime)?
No. It's definitely a crash from inside X, and almost certainly the ddx at fault. Ok, keep messing around for a bit and if it doesn't occur again over the w/e, I'll blame it on some bad electrons.
Ok, there it was again. Although, I'm not sure if the bisect is credible, anymore. I'll try with --enable-debug.
Maybe it's worth mentioning. There was no SIGSEGV under openbox, but video corrupiton. "Fixed" by screen recoding software, so captured with camcoder. https://www.dropbox.com/s/9i0586yvo1sehdl/IMG_0609.mp4?dl=0
Ugh, that corruption is dirty GPU cachelines. Mostly fixed by a later kernel (though I think only 4.2 will carry the right fixes). And there is always a possibility that we need more flushes (though that is something we would inject into the pipeline with the kernel).
Created attachment 117867 [details]
This is really strange. At least, I'm still getting a reproducible crash on YT in 5a9a3e7. Unfortunately, when compiled with --enable-debug, Xorg crashes in DM.
That's a pretty much impossible crash. Still crashes there with --enable-debug=full? We check when we set up the pageflip that the callback is valid, yet at the time of the pageflip the assertion fails that the callback is now NULL. Very suspicious.
Created attachment 117872 [details]
(In reply to Chris Wilson from comment #12)
> Still crashes there with --enable-debug=full?
Still crashes :(
Ah, 2.99.917-430-g5a9a3e7, sorry yes that a silly bug where I forgot the handler could recurse and so the assertions were too strong.
Created attachment 117876 [details]
Xorg.0.log.old - compiled with --enable-debug
I've no idea why the crash is no longer easily reproducible with 2.99.917.452.g78f7451, and it's bothering me a lot.
Here's a log from 441.g18e4845, revision picked randomly.
Created attachment 117877 [details]