While usually leaving xlock running on display for a while (i.e. 20 or minutes) I get busy looping Xorg with black screen. I've tried to capture some gdb backtrace of running Xorg & xlock (I've no idea which xlock mode was on display during this lock) sna git: cf5b3e2ebf4ee0330f5421b9377bb512a94ec284 xorg-x11-server-Xorg-1.12.1-2.fc18.x86_64 Here is short bt - more in attachments. 0x000000000056b3c1 in miZeroClipLine (xmin=0, ymin=0, xmax=xmax@entry=1679, ymax=ymax@entry=1049, new_x1=new_x1@entry=0x7ffff1df9848, new_y1=new_y1@entry=0x7ffff1df9850, new_x2=new_x2@entry=0x7ffff1df984c, new_y2=new_y2@entry=0x7ffff1df9854, adx=adx@entry=30057, ady=1319, pt1_clipped=pt1_clipped@entry=0x7ffff1df9858, pt2_clipped=pt2_clipped@entry=0x7ffff1df985c, octant=4, bias=1, bias@entry=216, oc1=<optimized out>, oc2=4) at mizerclip.c:510 510 eqn = (swapped) ? EQN2 : EQN1; ^[[?1034h(gdb) bt #0 0x000000000056b3c1 in miZeroClipLine (xmin=0, ymin=0, xmax=xmax@entry=1679, ymax=ymax@entry=1049, new_x1=new_x1@entry=0x7ffff1df9848, new_y1=new_y1@entry=0x7ffff1df9850, new_x2=new_x2@entry=0x7ffff1df984c, new_y2=new_y2@entry=0x7ffff1df9854, adx=adx@entry=30057, ady=1319, pt1_clipped=pt1_clipped@entry=0x7ffff1df9858, pt2_clipped=pt2_clipped@entry=0x7ffff1df985c, octant=4, bias=1, bias@entry=216, oc1=<optimized out>, oc2=4) at mizerclip.c:510 #1 0x00007f00b572fdcb in sna_poly_zero_segment_blt (drawable=drawable@entry=0x1f47630, bo=<optimized out>, damage=0x0, gc=gc@entry=0x1f85880, _n=_n@entry=114, _s=_s@entry=0x1f78d80, extents=0x7ffff1df9860, extents@entry=0x7ffff1dfaae0, clipped=2) at sna_accel.c:7155 #2 0x00007f00b5745a97 in sna_poly_segment (drawable=0x1f47630, gc=0x1f85880, n=114, seg=0x1f78d80) at sna_accel.c:7507 #3 0x0000000000503efe in damagePolySegment (pDrawable=0x1f47630, pGC=0x1f85880, nSeg=114, pSeg=<optimized out>) at damage.c:1052 #4 0x000000000043097d in ProcPolySegment (client=0x2381ee0) at dispatch.c:1742 #5 0x000000000043442a in Dispatch () at dispatch.c:425 #6 0x0000000000423495 in main (argc=4, argv=0x7ffff1dfbf68, envp=<optimized out>) at main.c:288
Created attachment 62328 [details] gdb session attached to the looping Xorg process If I should look up next time more info - let me know.
Created attachment 62329 [details] gdb session/backtrace from xlock process that has caused the issue If someone knows which parameter has encrypted running mode of xlock - would be nice to share - since I do not have free hours to spend on watching which mode has caused the looping.
Created attachment 62330 [details] Xorg log for details of X session
Can you grab an xtrace for the xlock process so that we can see the last drawing request?
Can you also disable optimisations and grab a fresh bt full?
I'll try to remember to start xlock through xtrace and leave it running and keep it logging next time I'll leave the machine for longer period of time. I've just fought that values: x1 = 0 y1 = -375 x2 = 14129 y2 = 7 x1_orig = -21350 y1_orig = -1312 x2_orig = 14129 y2_orig = 7 looks a bit weird - is the loop expected to handle such numbers ?
(In reply to comment #5) > Can you also disable optimisations and grab a fresh bt full? Any special configure options for sna driver build I should use ? (Eventually I could probably leave the machine running xlock in valgrinded Xorg during night)
(In reply to comment #6) > I'll try to remember to start xlock through xtrace and leave it running and > keep it logging next time I'll leave the machine for longer period of time. > > I've just fought that values: > > x1 = 0 > y1 = -375 > x2 = 14129 > y2 = 7 > x1_orig = -21350 > y1_orig = -1312 > x2_orig = 14129 > y2_orig = 7 > > looks a bit weird - is the loop expected to handle such numbers ? Yes, if that loop can't clip negative values, we're doomed! (And 14k wide isn't that large as Pixmaps go.) They struck me as odd values as well, but not outlandish. Do you know which xscreensaver this is? As far as compile options go, --enable-debug to see if blows up further, but the critical loop is inside the Xserver codebase itself, so we just want to take a close look at the inputs SNA is feeding it.
This looks to be the oddity: adx = 30057 x1 = -21350 x2 = 14129 where adx is meant to be adx = x2 >= x1 ? x2 - x1 : x1 - x2;
Try commit 660c89e9742bac5ce7cbd480e08b4667e37dee8c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu May 31 13:18:21 2012 +0100 sna: Use full 16-bit unsigned values for absolute differences Beware the overflow implicit in: adx = x2 >= x1 ? x2 - x1 : x1 - x2; when both x2 and x1 may be large signed 16-bit values Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50532 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Argh! Beware that has unwanted sign extension misery.
commit 90ae4f853222ee33206134f4efdc4accfb2f2c38 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu May 31 14:17:40 2012 +0100 sna: Avoid mixing signed/unsigned int/int16 arithmetric Should be ready for testing in anger now.
(In reply to comment #4) > Can you grab an xtrace for the xlock process so that we can see the last > drawing request? Naive question - how is one supposed to use xtrace with xlock ? When I run it just like: xtrace /bin/xlock I get just empty 'xterm' window - which isn't really useful. xtrace seems to belong to glibc-utils-2.15.90-3.fc18.x86_64 So I assume you mean some 'other' xtrace ?
Pretty sure I've caught the bug here. Regarding xtrace, I mean the one from http://xtrace.alioth.debian.org/ Alternatively you could use xscope or even wireshark.
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.