Hello, I am running the current release candidate and have problems with EXA. Regardless of having KMS enabled or disabled my XServer crashes when I try to open a window. Starting the desktop itself is fine, until the first window should be shown. I report this bug with having KMS and EXA disabled and XAA enabled instead. Fatal server error: exaGetPixmapFirstPixel called for invalid bpp 1 Software versions: xorg-server 1.7.0.902 xf86-video-ati 6.12.99.git20091014 ati-dri 7.6 mesa 7.6 Steps to reproduce: Start X and open a window. If you need anymore information, please let me know. Thank you!
Created attachment 30646 [details] Offending Xorg log
It would be interesting to get a gdb backtrace, preferably with debugging symbols available: * Attach gdb to the running X server (from a remote shell) * Set a breakpoint on FatalError * Continue execution and reproduce the problem * Enter 'bt full' at the gdb prompt after the breakpoint is hit Is the desktop environment KDE4, or something else? Any noteworthy configuration, e.g. non-anti-aliased fonts for window titles or so?
Unfortunately, I don't have enough time right now to rebuild my system with debug flags and to provide the request backtrace. Nevertheless, I found a workaround for the mentioned problem: As the xserver only crashed when a window was opened, it turned out to be triggered by the window decoration theme of XFCE. I have switched to another theme and EXA is now usable.
I've got the same bug since the latest update to xorg-server 1.7.1.901 on Arch Linux. It's not possible to start any software anymore with Xfce 4.6.1. This happens with several Xfwm themes. After downgrading to xorg-server 1.6.3.901 or changing the Xfwm theme to a working theme by editing the file ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml it's working again. But there are still problems with other Xfwm themes because menus or text lists are sometimes shown distorted. I'll attach the file slim.log which contains the console output of Xorg. If you need a gdb backtrace, please, tell me how I can do this.
Created attachment 31098 [details] slim.log This file contains the console output of Xorg with the relevant error messages.
I'd like to make a gdb backtrace but I've got only one computer and gdb doesn't let me switch to X. I found a documentation about debugging X from the same maching but it seems to be really unusable. So do you know if there's a way to debug Xorg from the same computer?
(In reply to comment #2) > Is the desktop environment KDE4, or something else? Any noteworthy > configuration, e.g. non-anti-aliased fonts for window titles or so? xfwm4 can use XPM for decorations. From the pixmap, it creates a larger pixmap in memory the size of the destination window and use it to set XSetWindowBackgroundPixmap() of the destination window. The problem occurs with a theme that uses 1x1 pixmaps with only 1 color.
(In reply to comment #7) > The problem occurs with a theme that uses 1x1 pixmaps with only 1 color. Nevertheless it must be a bug in Xorg because it worked with every previous Xorg version. The bug only occurs since xorg-server 1.7.1.901 resp. 1.7.0.902. Otherwise you probably should contact the Xfce devs. See my bug report for Xfce: http://bugzilla.xfce.org/show_bug.cgi?id=5966 I don't know if this is related to this bug - I can't test it with the other Xfce themes ;-) -, but when using Xfce themes which don't lead to X crashes the output of some software like Osmo isn't shown correctly anymore. See the attached screenshot. When I move the mouse over the distorted areas the distortion is removed and the software output is displayed correctly again. This also happens only since the latest Xorg update.
Created attachment 31108 [details] Osmo-screenshot.png A screenshot of Osmo how it looks since xorg-server 1.7.1.901. The same happens with other (not every) software, too.
I don't know if this helps, but at least for me this problem only occurs with the ati (radeon) and radeonhd drivers. With catalyst (fglrx) this issue doesn't exist.
I humbly like to ask what the status on this one is. ATM I have to take care remember or move offending themes out of the way, otherwise X would just die on me upon theme switch.
(In reply to comment #11) > I humbly like to ask what the status on this one is. Still waiting for a gdb backtrace.
In 4 days this bug will be one year old. It is still present in 1.9.0. Reproducing is still easy: 0. Run X with EXA. 1. Run xfce. 2. Choose e.g. the Wildbush window manager theme which is part of the xfce theme collection. 3. Enjoy your xorg crash. When googling "xfce" and "wildbush" one finds many people who have this problem. There's also an entry in the ubuntu bugtracker: https://bugs.launchpad.net/ubuntu/+source/xfwm4-themes/+bug/573516 Gentoo: http://bugs.gentoo.org/310625 Not xfce-theme related, but probably same bug ("the xserver calls the FatalError when the bpp of the pixmap is 1."): http://lists.freedesktop.org/archives/xorg/2010-January/048819.html > Still waiting for a gdb backtrace. How about some instructions about how to get a stacktrace without gdb hanging, xorg hanging or other stuff that's not so easy to solve for someone not so experienced with debugging xorg? I would totally give ssh access, but I don't really believe that none of the developers who are responsible for this part of the code runs EXA and couldn't test him-/herself.
After reading this thread I'm wondering if it would be better for us to file bug reports with the xorg package maintainers for our various distributions since it doesn't seem that the Xorg Project Team is very interested in the problem. I'm running Debian testing with Xfce on a system using the Nouveau driver. It is adversely affected by this. It's easy enough to remove the offending theme (Wildbush) from the system, but it's hard to understand why it wouldn't a better idea to fix the actual source of the problem instead of just trying to block the symptoms.
I can reproduce the bug locally with the nouveau driver (yet I cannot with intel driver), I'll try to investigate this a bit on the X server side and update this bz accordingly.
This is the backtrace: (gdb) break exaGetPixmapFirstPixel Breakpoint 1 at 0x7fca06403954: file exa_unaccel.c, line 732. (gdb) cont Continuing. Breakpoint 1, exaGetPixmapFirstPixel (pPixmap=0x11e8160) at exa_unaccel.c:732 732 { (gdb) bt #0 exaGetPixmapFirstPixel (pPixmap=0x11e8160) at exa_unaccel.c:732 #1 0x00007fca063fd217 in exaFillRegionTiled (pDrawable=0x1339e40, pRegion=0x1169a70, pTile=0x11e8160, pPatOrg=0x11af9a8, planemask=4294967295, alu=3, clientClipType=0) at exa_accel.c:1105 #2 0x00007fca063fd875 in exaPolyFillRect (pDrawable=0x1339e40, pGC=0x11af960, nrect=1, prect=0x1349a50) at exa_accel.c:821 #3 0x00000000004ac8b1 in damagePolyFillRect (pDrawable=0x1339e40, pGC=0x11af960, nRects=1, pRects=0x1349a50) at damage.c:1396 #4 0x00000000004282e5 in ProcPolyFillRectangle (client=<value optimized out>) at dispatch.c:1868 #5 0x000000000042b02e in Dispatch () at dispatch.c:432 #6 0x00000000004215da in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:291 (gdb) cont Continuing. Breakpoint 1, exaGetPixmapFirstPixel (pPixmap=0x1150cd0) at exa_unaccel.c:732 732 { (gdb) Continuing. Program exited with code 01. 27 * Gets the 0,0 pixel of a pixmap. Used for doing solid fills of tiled pixmaps 728 * that happen to be 1x1. Pixmap must be at least 8bpp. 729 */ 730 CARD32 731 exaGetPixmapFirstPixel (PixmapPtr pPixmap) 732 { 733 switch (pPixmap->drawable.bitsPerPixel) { 734 case 32: 735 { 736 CARD32 pixel; 737 738 pPixmap->drawable.pScreen->GetImage(&pPixmap->drawable, 0, 0, 1, 1, 739 ZPixmap, ~0, (char*)&pixel); 740 return pixel; 741 } 742 case 16: 743 { 744 CARD16 pixel; 745 746 pPixmap->drawable.pScreen->GetImage(&pPixmap->drawable, 0, 0, 1, 1, 747 ZPixmap, ~0, (char*)&pixel); 748 return pixel; 749 } 750 case 8: 751 { 752 CARD8 pixel; 753 754 pPixmap->drawable.pScreen->GetImage(&pPixmap->drawable, 0, 0, 1, 1, 755 ZPixmap, ~0, (char*)&pixel); 756 return pixel; 757 } 758 default: 759 FatalError("%s called for invalid bpp %d\n", __func__, 760 pPixmap->drawable.bitsPerPixel); 761 } 762 }
Created attachment 41295 [details] full gdb backtrace Breaking on the offending fatal error give: (gdb) break exa_unaccel.c:759 Breakpoint 1 at 0x7fd32a03ea1a: file exa_unaccel.c, line 759. (gdb) cont Continuing. Breakpoint 1, exaGetPixmapFirstPixel (pPixmap=0x13b5970) at exa_unaccel.c:759 759 FatalError("%s called for invalid bpp %d\n", __func__, (gdb) bt #0 exaGetPixmapFirstPixel (pPixmap=0x13b5970) at exa_unaccel.c:759 #1 0x00007fd32a038217 in exaFillRegionTiled (pDrawable=0x14ee1c0, pRegion=0x1402290, pTile=0x13b5970, pPatOrg=0x13f6e38, planemask=4294967295, alu=3, clientClipType=0) at exa_accel.c:1105 #2 0x00007fd32a038875 in exaPolyFillRect (pDrawable=0x14ee1c0, pGC=0x13f6df0, nrect=1, prect=0x151dbf4) at exa_accel.c:821 #3 0x00000000004ac8b1 in damagePolyFillRect (pDrawable=0x14ee1c0, pGC=0x13f6df0, nRects=1, pRects=0x151dbf4) at damage.c:1396 #4 0x00000000004282e5 in ProcPolyFillRectangle (client=<value optimized out>) at dispatch.c:1868 #5 0x000000000042b02e in Dispatch () at dispatch.c:432 #6 0x00000000004215da in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:291 Full backtrace attached.
Created attachment 41297 [details] full gdb backtrace More details.
Created attachment 41299 [details] [review] Possible fix? Thanks for the detailed information, Olivier. Would this patch happen to fix the problem?
(In reply to comment #19) > Thanks for the detailed information, Olivier. Would this patch happen to fix > the problem? At first sight it should definitely help indeed :-) Yeap, applied, tested, worksforme!
commit e06fa804009798ea95efa8babaabb0228dfdfe65 Author: Michel Dänzer <daenzer@vmware.com> Date: Wed Dec 22 11:45:36 2010 +0100 EXA: Fix crash with fill using 1x1 tile of depth < 8 (bug #24703). Fixes http://bugs.freedesktop.org/show_bug.cgi?id=24703 . Signed-off-by: Michel Dänzer <daenzer@vmware.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Keith Packard <keithp@keithp.com>
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.