Bug 24703

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>