Created attachment 125094 [details] Xorg.0.log.old I can reproduce this on glamor/modesetting and xf86-video-intel with DRI3 enabled unless I set Option "PageFlip" "0". waiting for X server to shut down X: /var/tmp/portage/x11-base/xorg-server-9999/work/xorg-server-9999/present/present_screen.c:95: present_clear_window_flip: Assertion `flip_pending->abort_flip' failed. On Slackware I can't recover any tty and have to hit the power button. Gentoo allows me to exit and logout, but the tty doesn't display properly. I have git version of mesa and xorg-server as of today. I attached dmesg, Xorg.0.log and the nohup.out I needed to get the assert.
Created attachment 125095 [details] 4.6.4 dmesg
Created attachment 125096 [details] the assert
It seems this only happens with compton running with --backend "glx".
I think I ran into this assertion before, but I can't seem to reproduce it right now. What kind of desktop session are you running, and how are you starting and leaving it? Can you: * Log into the machine remotely, and attach gdb to the Xorg process * Reproduce the problem * Run "bt full" at the gdb prompt when the assertion fails and then attach the resulting backtrace here? See https://www.x.org/wiki/Development/Documentation/ServerDebugging/ for some background information.
Is this maybe related? https://bugs.freedesktop.org/show_bug.cgi?id=94515 Despite my best efforts my gdb session seems to be lacking and they all look very similar to the one I attached. Sorry. :/ Not sure what I'm doing wrong. Only happens with DRI3. My test case is simply startx with a .xinitrc: compton -b --backend glx exec uxterm compton-trans 90 <click xterm> # since sometimes compton's --opacity-rule "90:class_g='UXTerm" sometimes doesn't work... sleep 90 ; exit # since the host display will freeze upon attach <go attach remotely> When run through gdb the host doesn't show an assert, just "refuses to die".
Created attachment 125357 [details] gdb session 1
(In reply to Tod Jackson from comment #5) > Is this maybe related? > https://bugs.freedesktop.org/show_bug.cgi?id=94515 I don't think so. > Despite my best efforts my gdb session seems to be lacking and they all look > very similar to the one I attached. Sorry. :/ Not sure what I'm doing wrong. Maybe try running handle SIGTERM nostop noprint when attaching gdb to Xorg, before continuing its execution and reproducing the problem. BTW, you only need to get a backtrace after it actually failed the assertion. > My test case is simply startx with a .xinitrc: Thanks; I was already trying something similar, but despite trying to match your steps even more closely, I'm not able to reproduce it right now unfortunately.
How strange, with your suggestion, handle SIGTERM nostop noprint, I don't get any assert and everything exits normally.
Sigh, sounds like gdb somehow affects the execution (timing?) such that the problem doesn't happen. Next idea: Use startx -- -core to start X, which should hopefully generate a core dump of the Xorg process after the crash (you may need to use ulimit to enable core dumps for the Xorg process). Then use gdb /path/to/Xorg <core dump file> to run gdb with the core dump, and run "bt full" at its prompt.
Created attachment 125359 [details] startx -- -core dump
I see you made a commit about this but I can't test because now Xorg breaks for me completely. I attached the Xorg log.
Created attachment 125390 [details] startx intel_drv randr? segfault
(In reply to Tod Jackson from comment #11) > I see you made a commit about this That fixes a different crash I was hitting while trying to reproduce this one, but I'm afraid it doesn't fix this one. > but I can't test because now Xorg breaks for me completely. I attached the > Xorg log. That's a separate bug and should be tracked separately, ideally with a gdb backtrace.
Created attachment 125402 [details] [review] present: Call set_abort_flip / restore_screen_pixmap in clear_window_flip Does this patch fix the problem?
I'm not able to do a proper test right now but maybe you can make something of this attachment. Patched against 1.18.4.
Created attachment 125416 [details] 1.18.4 after patch1
That seems to fix it on modesetting but not intel. Am attaching a better version of the core dump (didn't have intel symbols before, I believe). Probably unrelated but sometimes when I did compton --backend glx on modesetting the terminal would disappear completely, even without changing its opacity.
Created attachment 125423 [details] after patch with intel
Created attachment 125477 [details] [review] present: Make present_restore_screen_pixmap handle screen->root == NULL Please try this patch together with the previous one.
Those two patches fix the issue on both intel and modesetting. :)
Merged, thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.