I've been following the git master of Xorg. I tried viewing a magicpoint presentation today and X aborted. The first slide displays properly (it's basically text). The second is also simple text, displays as it should, but then X crashes. I captured the message from startx shown in the summary on a remote screen. I very vaguely recall having a similar problem with pixman several months ago. This happens only on one of the machines I tried it on. This uses the radeon ati driver.
I rebuilt pixman and xserver with debugging symbols (-O0 -g), attached gdb to X and triggered the bug. r looks reasonable, except that r->x1 = 1224 (r->y1=0), r->x2=1220 (r->y2=768)
Thanks for the bug report. Can you post a backtrace, and also the complete contents of the 'r' region (ie., "p *r" in gdb). Generally, when assertions are triggered in pixman it has been because the X server is doing something wrong, so it would be useful to see where this is coming from.
Created attachment 31554 [details] gdb output captured with logging I logged the gdb session. The information you want is probably at the end. Note: p *r gave the same information I'd manually entered in the initial report.
Could you try compiling pixman again with "-g -O0", but this time also adding #define PIXMAN_REGION_DEBUG at the top of pixman-region.c?
Hopefully that will produce some useful debug spew in the Xorg log file.
I added the define as per your request and reran the program. I still get an abort at the same point in magicpoint, but now at a different point in pixman. I'll attach the log file generated from within ddd/gdb. There was no extra output in Xorg's log file. Note that there is some print out towards then end. This is the output of print *reg[12].
Created attachment 31784 [details] ddd/gdb log file
What's going on here is that the 65532 in this: #7 0x08121e03 in damageCopyArea (pSrc=0x86a4378, pDst=0x86a4378, pGC=0x87562c0, srcx=1224, srcy=0, width=65532, height=768, d stx=1232, dsty=0) at damage.c:949 ends up generating a region containing a box with negative width. That is what causes the assert in pixman to fail. Overflows of signed types are undefined in C, but assuming the obvious behavior, this actually does work, so in the recently-released pixman 0.16.4, the assert is turned off. I don't think the server should be relying on this kind of thing, but it is difficult to see any way to fix this apart from moving to 32 bit regions, so I am moving and retitling the bug to reflect that.
Thanks Is there a simple workaround? This is my main presentation software.
I forgot to mention that newly-released pixman 0.16.4 disables this assert, so installing that should make it work (if it doesn't, please let me know).
I just upgraded to the git/master of pixman (as well as xserver and several other modules). The problem remains.
Forget comment #11. Turns out it was finding another (older) copy of pixman. When I upgraded it the problem goes away.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/386.
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.