Yakuake + Compiz/Beryl + multiple shells = X Crash

[3vi1]

Binary package hint: yakuake

I can reproduce this consistently using Compiz or Beryl with Yakuake within Kubuntu 64-bit Feisty and Gutsy:

1) Start some process that utilizes most of your CPU. (I use Seti@Home)
2) Open Yakuake and start a long-running process that will scroll text. (I compile Wine).
3) Open a second tab in Yakuake, such that the first shell is hidden.
4) Press your hotkey to minimize the Yakuake window.

Within seconds, if not immediately, the entire desktop will crash and restart - dumping you at the KDM login screen.

I am using Gutsy with the current nvidia-glx-new (1.0.9755) drivers. My video hardware is an nVidia 7600GT.

[Raul Sanchez Siles (rasasi78)]

Created an attachment (id=9569)
Xorg log for the crash.

[Raul Sanchez Siles (rasasi78)]

Created an attachment (id=9570)
Xorg configuration file

[Raul Sanchez Siles (rasasi78)]

I forgot to say that I own a Dell 510m laptop with a intel855GM video card.
0:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

00:02.0 0300: 8086:3582 (rev 02)
00:02.1 0380: 8086:3582 (rev 02)

[Michel-tungstengraphics (michel-tungstengraphics)]

Can you get a log file (or even better, a gdb backtrace) with the xserver-xorg-core-dbg package installed?

[Raul Sanchez Siles (rasasi78)]

I reproduce the crash with the xserver-xorg-core-dbg package installed and the log I got is quite the same, anyway I attach it.

Maybe I should have also said that I'm using transparencies and translucencies on kde, yet the yakuake use transparent backgroun, at least kind of.

[Raul Sanchez Siles (rasasi78)]

Created an attachment (id=9575)
Xorg log for the crash with debugging package installed.

[Raul Sanchez Siles (rasasi78)]

I managed to get a somewhat meaningful backtrace of the crash. Here you are:
#0 0xb7ef9410 in __kernel_vsyscall ()
#1 0xb7d1a791 in raise () from /lib/i686/cmov/libc.so.6
#2 0xb7d1c008 in abort () from /lib/i686/cmov/libc.so.6
#3 0x080a0be6 in ddxGiveUp () at ../../../../hw/xfree86/common/xf86Init.c:1234
#4 0x081bdaa3 in AbortServer () at ../../os/log.c:407
#5 0x081bdfb7 in FatalError (
    f=0x81c8d7c "Caught signal %d. Server aborting\n") at ../../os/log.c:553
#6 0x080c20e7 in xf86SigHandler (signo=11)
    at ../../../../hw/xfree86/common/xf86Events.c:1460
#7 <signal handler called>
#8 0x08172b92 in cwGetBackingPicture (pPicture=0x879cb18, x_off=0xbfc359c0,
    y_off=0xbfc359bc) at ../../../miext/cw/cw_render.c:129
#9 0x08172e4c in cwGlyphs (op=3 '\003', pSrcPicture=0x8bb84d8,
    pDstPicture=0x879cb18, maskFormat=0x8219728, xSrc=0, ySrc=0, nlists=1,
    lists=0xbfc35f08, glyphs=0xbfc35b08) at ../../../miext/cw/cw_render.c:297
#10 0x0816f325 in damageGlyphs (op=3 '\003', pSrc=0x8bb84d8, pDst=0x879cb18,
    maskFormat=0x8219728, xSrc=0, ySrc=0, nlist=1, list=0xbfc35f08,
    glyphs=0xbfc35b08) at ../../../miext/damage/damage.c:654
#11 0x0815588a in CompositeGlyphs (op=3 '\003', pSrc=0x8bb84d8,
    pDst=0x879cb18, maskFormat=0x8219728, xSrc=0, ySrc=0, nlist=1,
    lists=0xbfc35f08, glyphs=0xbfc35b08) at ../../render/picture.c:1824
#12 0x0815d468 in ProcRenderCompositeGlyphs (client=0x8515a08)
    at ../../render/render.c:1401
#13 0x08158915 in ProcRenderDispatch (client=0x0) at ../../render/render.c:1999
#14 0x0814bd0e in XaceCatchExtProc (client=0x8515a08) at ../../Xext/xace.c:299
#15 0x080883cb in Dispatch () at ../../dix/dispatch.c:457
#16 0x080701f9 in main (argc=8, argv=0xbfc36784, envp=
Cannot access memory at address 0x8
) at ../../dix/main.c:477

[Raul Sanchez Siles (rasasi78)]

Maybe according to the backtrace this hasn't been, strictly speaking, a problem with the driver, but I didn't have the same problem with the previous i810 driver.

There's a major difference when I use the KDE translucencies graphical effects and when I don't. And the difference is that when I don't use mean the problem is not repeatable. I don't exactly know what using translucencies could mean in Xorg using features, but what I know is that in the translucencies mode, a composite manager is used. Also yaluake is using the konsole settings which, in turn shows the bacground desktop image transparency-like.

Since this is a complicated problem to repeat not because of its lack of repeatibility, but because of the amount of especifical programs needed I decided to used the core dump file I have from the crash to get more information.

I've inspected the variables values from the core file using gdb:

The crash happens exactly on the macro cwDstPictureDecl in the cwGlyphs function. Here are the backtrace and some useful variable information:

Frame #9:
#9 0x0817270d in cwGlyphs (op=3 '\003', pSrcPicture=0x8973ab8,
    pDstPicture=0x91c1ef0, maskFormat=0x8219610, xSrc=0, ySrc=0, nlists=1,
    lists=0xbfa25fe8, glyphs=0xbfa25be8) at ../../../miext/cw/cw_render.c:297

p *pSrcPicture
$3 = {pDrawable = 0x86fb3d8, pFormat = 0x8219610, format = PICT_a8r8g8b8,
  refcnt = 1, id = 35651999, pNext = 0x0, repeat = 1, graphicsExposures = 0,
  subWindowMode = 0, polyEdge = 0, polyMode = 0, freeCompClip = 1,
  clientClipType = 0, componentAlpha = 0, repeatType = 1, unused = 2090695,
  alphaMap = 0x0, alphaOrigin = {x = 0, y = 0}, clipOrigin = {x = 0, y = 0},
  clientClip = 0x0, dither = 0, stateChanges = 0, serialNumber = 9719,
  pCompositeClip = 0x86fc908, devPrivates = 0x8973b0c, transform = 0x0,
  filter = 0, filter_params = 0x0, filter_nparams = 0, pSourcePict = 0x0}
p *pDstPicture
$4 = {pDrawable = 0x8f26d68, pFormat = 0x8219670, format = PICT_x8r8g8b8,
  refcnt = 1, id = 35672205, pNext = 0x0, repeat = 0, graphicsExposures = 0,
  subWindowMode = 0, polyEdge = 0, polyMode = 0, freeCompClip = 0,
  clientClipType = 0, componentAlpha = 0, repeatType = 0, unused = 12064,
  alphaMap = 0x0, alphaOrigin = {x = 0, y = 0}, clipOrigin = {x = 0, y = 0},
  clientClip = 0x0, dither = 0, stateChanges = 0, serialNumber = 4021270,
  pCompositeClip = 0x8f26d94, devPrivates = 0x91c1f44, transform = 0x0,
  filter = 0, filter_params = 0x0, filter_nparams = 0, pSourcePict = 0x0}

p *lists
$6 = {xOff = 101, yOff = 60, len = 4 '\004', format = 0x8219610}

p *lists->format
$7 = {id = 54, format = 166024, type = 1 '\001', depth = 32 ' ', direct = {
    red = 16, redMask = 255, green = 8, greenMask = 255, blue = 0,
    blueMask = 255, alpha = 24, alphaMask = 255}, index = {vid = 0,
    pColormap = 0x0, nvalues = 0, pValues = 0x0, devPrivate = 0x0}}

p **glyphs
$10 = {refcnt = 8, devPrivates = 0x0, size = 192, info = {width = 5,
    height = 9, x = -1, y = 9, xOff = 7, yOff = 0}}

PictureScreenPrivateIndex=7
p pDstPicture->pDrawable->pScreen->devPrivates[7].ptr
$17 = (pointer) 0x8218268

cwScreenIndex=13
p pDstPicture->pDrawable->pScreen->devPrivates[13].ptr
$19 = (pointer) 0x82...

[rysiek (mikiwoz)]

well reproducible both on ATI Radeon9600 running the open-sorce radeon driver and on nVidia GeForce7600 running the nVidia's proprietary driver; only happens when using either compiz or beryl (happened to me on both), haven't tried the KDE effects though.

on "normal" KDE desktop (no translucency/3d effects) the crash does not occur (at least to me).

cheers
mike

[3vi1 (launchpad-net-eternaldusk)]

Binary package hint: yakuake

I can reproduce this consistently using Compiz or Beryl with Yakuake within Kubuntu 64-bit Feisty and Gutsy:

1) Start some process that utilizes most of your CPU. (I use Seti@Home)
2) Open Yakuake and start a long-running process that will scroll text. (I compile Wine).
3) Open a second tab in Yakuake, such that the first shell is hidden.
4) Press your hotkey to minimize the Yakuake window.

Within seconds, if not immediately, the entire desktop will crash and restart - dumping you at the KDM login screen.

I am using Gutsy with the current nvidia-glx-new (1.0.9755) drivers. My video hardware is an nVidia 7600GT.

[Max Kostovetski (fiendware)]

See http://bugs.gentoo.org/show_bug.cgi?id=158395

[Rich Johnson (nixternal)]

Confirming due to response and link to Gentoo bug. I will get in touch with the Yakuake dev and see what the issue may be related to. Thanks for the report and the response.

[Jesse Barnes (jbarnes-virtuousgeek)]

Changing this to a generic server bug, since it happens with radeon as well.

Raul, can you try again with a more recent xserver and update the "version" field if the bug still exists?

[Raul Sanchez Siles (rasasi78)]

Hello.

Just tried again with the latest Debian unstable xserver package and got to the same fault. This is version 1.3 of Xorg(Xserver?) but I'm not sure about how versions are working in Xorg, sorry.

Maybe it will be clearer in the Xorg log I attach which include the crash backtrace.

[Raul Sanchez Siles (rasasi78)]

Created an attachment (id=11091)
Freshes Xorg log (with 1.3 version of the protocol)

[Tanguy Herrmann (dolanor)]

Without multiple shell, I can crash it too.
It is always when the yakuake console hide.

ubuntu feisty 32bits/nVidia drivers (nvidia-glx) (GeForce 7600 GS)/compiz-fusion

[Nighto (nighto-nighto)]

Same thing here, running Ubuntu Gutsy Beta with Compiz Fusion in GNOME, with an i945 card on Acer TravelMate 2480.

[Maarten Fonville (maarten-fonville)]

I can confirm this bug on Kubuntu Gutsy Final with Compiz Fusion

[3vi1 (launchpad-net-eternaldusk)]

Even after completely re-installing, I can re-create this bug with ease: Kubunutu AMD64 7.10 final.

[salva (salva-lorenzo)]

Same problem with my kubuntu gutsy system with compiz-fusion, you can reproduce it launching any graphic application from yakuake.

The problem persist with or without auto-hiding function of yakuake.

Problem doesnt appear if i launch from konsole.

It seems a yakuake problem ...

[Bugs-freedesktop-org-eternaldusk (bugs-freedesktop-org-eternaldusk)]

I can recreate this same bug with an nVidia 7600GT under Kubuntu 7.04 & 7.10 AMD64, with the additional considerations:

To consistently recreate the bug, I have to open a second Yakuake tab - and have some app scrolling text in the (hidden) first.

I have only had this crash while Beryl or Compiz are loaded.

[raphxl (raphxl)]

Same pb for me with Gusty using Intel Corporation Mobile 945GM/GMS and ATI Radeon on 2 notebooks. Pb appears since I upgraded from an updated feisty on the older notebook. When compiz disabled, all went good.

[kelvie (kelvie)]

(In reply to comment #13)
> I can recreate this same bug with an nVidia 7600GT under Kubuntu 7.04 & 7.10
> AMD64, with the additional considerations:
>
> To consistently recreate the bug, I have to open a second Yakuake tab - and
> have some app scrolling text in the (hidden) first.
>
> I have only had this crash while Beryl or Compiz are loaded.
>

I can reproduce this also, I use xorg-server-1.4 (that's xorg-x11-7.3) on x86_64/gentoo and x86/gentoo as well.

[kelvie (kelvie)]

Program received signal SIGSEGV, Segmentation fault.
0xb7a42ac2 in miInitializeCompositeWrapper ()
   from /usr/lib/xorg/modules//libxaa.so
(gdb) bt
#0 0xb7a42ac2 in miInitializeCompositeWrapper ()
   from /usr/lib/xorg/modules//libxaa.so
#1 0xb7a42d7c in miInitializeCompositeWrapper ()
   from /usr/lib/xorg/modules//libxaa.so
#2 0x081715fa in DamageDamageRegion ()
#3 0x081588ca in CompositeGlyphs ()
#4 0x081601e2 in PanoramiXRenderReset ()
#5 0x0815b605 in AllocatePicturePrivate ()
#6 0x0814ee3e in XaceHook ()
#7 0x0808d7a0 in Dispatch ()
#8 0x08074c05 in main ()

Here;s ny backtrace -- looks more useful than the previous one.

To reproduce, run "yes" on one tab. Open up another one. Close Yakuake.

Crashes every time.

[Martin-marsark (martin-marsark)]

I can recreate this same bug with an nVidia 7600GT, x86/gentoo, kde 3.5.7, compiz-fusion 0.6.0 and Yakuake 2.8.

X will hit every time as described before.

[Patrick Taylor Ramsey (ptr-cs)]

Same problem for me. I'm using yakuake on gutsy (in gnome), on an athlon 1800+ (ia32) with an nVidia geForce3. I'm not sure if the same problem was there in feisty, because I didn't start using compiz-fusion regularly until gutsy. I've been reproducing it reliably (usually takes a few seconds) by running a couple cpu-intensive mencoder processes in yakuake, then doing *anything* else in any other application. Took me a long time to realize yakuake was the culprit, because it's the only terminal I use these days, and less resource-intensive processes (even firefox) didn't cause x to crash.

[Adam Porter (alphapapa)]

Yep. I had been trying the latest Fusions and they kept crashing X,
so I just thought Fusion was unstable, or that the NVIDIA driver was.
But I had forgotten that I use Yakuake, and that it has problems with
Compiz/Fusion. I even got crashes while Yakuake wasn't on-screen. As
soon as I stopped using Yakuake (which is painful! I use it all the
time!), the crashes stopped, and I can use Compiz/Fusion all I want.
:/

[Marcel Partap (empee584)]

Yes, this is the one I've been hitting since .. very long time. As I use yakuake intensively everytime in the last 1-2 years I tried switching on the KWin kompmgr translucency stuff, within minutes I triggered this crash and switched it off again. Now this time, I left it on and tried to trakc it down but without much success. I am running gent0o and compiled xorg-server-1.4-r2 with -ggdb and nostrip, however the backtrace in the Xorg.0.log.old only gives
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x6a) [0x48167a]
1: /lib/libc.so.6 [0x2b0de52881f0]
2: /usr/lib64/xorg/modules//libxaa.so [0x2b0de82cf99c]
3: /usr/lib64/xorg/modules//libxaa.so [0x2b0de82cfd03]
4: /usr/bin/X [0x523d35]
5: /usr/lib64/xorg/modules/drivers//nvidia_drv.so(_nv000961X+0x93) [0x2b0de7828df3]

Fatal server error:
Caught signal 11. Server aborting
although libxaa is not stripped. Also the core files I tried to produce didn't quite yield any result. But I think the problem has already been pinned down by the other backtraces, no?

[Brice Goglin (brice-goglin)]

Matthias Berndt reported the same problem in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453069
using Xserver 1.4.

To reproduce, he does:
1. enable compositing for kwin (to do this, run "kcmshell kwinoptions" and
enable Tranparency and drop shadows there).
2. start yakuake (a quake-style terminal emulator for KDE).
3. in a yakuake terminal, start mplayer with some audio file.
4. Open a new tab in yakuake (Ctrl-Alt-N).
5. hide yakuake (by pressing F12).
Xorg now crashes.

He also provided a full debug gdb backtrace at http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;filename=stack.txt;att=1;bug=453069

[Davide Saurino (dsaurino)]

Same problem for me.
I run yakuake with compiz fusion and nvidia drivers.
I am able to reproduce it every time I want. I only need to:
- open two tabs in yakuake;
- start an ssh session with a new process in every tab;
- every time I mimize yakuake Gnome crashes and I am sent back to GDM.

[Matthias (matthias-berndt)]

So, how is this coming along?

[Zoro (daniel-hunt4)]

I can confirm this in Gnome (Ubuntu 7.10: Gutsy + Compiz) too.

Frustrating is _not_ the word

[Zoro (daniel-hunt4)]

Actually, I'll add that yakuake is 100% unuseable for me due to this bug

[Abhinay Mukunthan (lexxonnet)]

Hello there,

There exists a similar bug report on Launchpad for Ubuntu Distros. I'm adding a link to that bug report here, and a link to this one there.

https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/165093

[Rich Johnson (nixternal)]

Confirmed as not being a Yakuake issue by X devs and other upstream devs. Yakuake only enhances the issue in X when utilizing compositing features.

[Zoro (daniel-hunt4)]

I missed this...

Of course you can mark it as invalid if you want, but the app is still unusable. As an end user I couldn't care less why something is happening, I just want it fixed so I can continue to use what is easily one of the most useful apps available in Linux

[erolosty (danielharkin)]

http://ubuntuforums.org/showthread.php?t=760102

This is still here in Hardy.

[erolosty (danielharkin)]

Hacked the problem out of 2.8.1 see http://www.kde-apps.org/content/show.php

[Zaar Hai (haizaar)]

The link is broken

[Uber-cow (uber-cow)]

(In reply to comment #18)
> Matthias Berndt reported the same problem in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453069
> using Xserver 1.4.
>
> To reproduce, he does:
> 1. enable compositing for kwin (to do this, run "kcmshell kwinoptions" and
> enable Tranparency and drop shadows there).
> 2. start yakuake (a quake-style terminal emulator for KDE).
> 3. in a yakuake terminal, start mplayer with some audio file.
> 4. Open a new tab in yakuake (Ctrl-Alt-N).
> 5. hide yakuake (by pressing F12).
> Xorg now crashes.
>
> He also provided a full debug gdb backtrace at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;filename=stack.txt;att=1;bug=453069
>

Reproducible here too, x86_64 gentoo with xorg 7.3 and intel drivers. I have a very similar backtrace to the onen above. This also seems to happen with some other actions, but (I think) only when something is running in a yakuake terminal.

[Robie Basak (racb)]

I think I'm seeing the same bug, except that in my case it seems to be related to the Adobe (binary) flash plugin for Firefox - of course no user application (binary or not) should be able to cause the X server to crash.

This is with xserver-xorg on Ubuntu (Hardy) 1:7.3+10ubuntu10.2 on x86_64 on an "Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)" (Chipset: "945GM")

The Ubuntu bug for my problem is here:

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/241145

Just so that it's all in one place, the other Ubuntu bug that I think this is the same as is here:

https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/165093

Xorg.0.log(.old):
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x6a) [0x48402a]
1: /lib/libc.so.6 [0x2b7bda1f7100]
2: /usr/lib/xorg/modules//libxaa.so [0x2b7bdd265c9c]
3: /usr/lib/xorg/modules//libxaa.so [0x2b7bdd265e96]
4: /usr/bin/X [0x527ea2]
5: /usr/bin/X [0x515c3f]
6: /usr/bin/X(Dispatch+0x2ef) [0x44eaaf]
7: /usr/bin/X(main+0x47d) [0x436b9d]
8: /lib/libc.so.6(__libc_start_main+0xf4) [0x2b7bda1e31c4]
9: /usr/bin/X(FontFileCompleteXLFD+0x279) [0x435ed9]

Full backtrace:
#0 0x00002aae2ef15c9c in cwGetBackingPicture (pPicture=0x2601310,
    x_off=0x7fff803e24c4, y_off=0x7fff803e24c0)
    at ../../../miext/cw/cw_render.c:128
 pPixmap = (PixmapPtr) 0x0
#1 0x00002aae2ef15e96 in cwComposite (op=3 '\003',
    pSrcPicture=<value optimized out>, pMskPicture=0x2ec0090,
    pDstPicture=0x2601310, xSrc=0, ySrc=0, xMsk=0, yMsk=0, xDst=0, yDst=256,
    width=256, height=24) at ../../../miext/cw/cw_render.c:271
 ps = (PictureScreenPtr) 0x83e540
 pCwScreen = (cwScreenPtr) 0x854a90
 src_picture_x_off = 0
 src_picture_y_off = 0
 pBackingSrcPicture = (PicturePtr) 0x3906850
 msk_picture_x_off = 0
 msk_picture_y_off = 0
 pBackingMskPicture = (PicturePtr) 0x2ec0090
 dst_picture_x_off = 0
 dst_picture_y_off = 16
 pBackingDstPicture = <value optimized out>
#2 0x0000000000527ea2 in damageComposite (op=16 '\020', pSrc=0x3906850,
    pMask=0x2ec0090, pDst=0x2601310, xSrc=-11168, ySrc=-9664, xMask=-2,
    yMask=<value optimized out>, xDst=<value optimized out>,
    yDst=<value optimized out>, width=<value optimized out>,
    height=<value optimized out>) at ../../../miext/damage/damage.c:580
 ps = (PictureScreenPtr) 0x83e540
 pScrPriv = (DamageScrPrivPtr) 0x8540e0
#3 0x0000000000515c3f in ProcRenderComposite (client=0x905230)
    at ../../render/render.c:758
 pSrc = (PicturePtr) 0x7fff803e24c4
 pMask = (PicturePtr) 0x2
 pDst = (PicturePtr) 0x0
#4 0x000000000044eaaf in Dispatch () at ../../dix/dispatch.c:502
 clientReady = <value optimized out>
 result = <value optimized out>
 client = (ClientPtr) 0x2eb3200
 nready = 0
 start_tick = 15200
#5 0x0000000000436b9d in main (argc=10, argv=0x7fff803e2bd8,
    envp=<value optimized out>) at ../../dix/main.c:452
 i = 1
 error = 0
 xauthfile = <value optimized out>
 alwaysCheckForInput = {0, 1}

[Robie Basak (racb)]

Setting severity blocker as this is a server crash (I'm following the instructions on XorgTriage).

The problem seems to be a null dereference on pPixmap in cwGetBackingPicture.

I don't understand what this function is meant to do, but I've looked at it. Should:
  DrawablePtr pDrawable = pPicture->pDrawable;
actually be:
  DrawablePtr pDrawable = pPicturePrivate->pDrawable;
? As I say...I don't know what this function does, but I don't see why pPicturePrivate is being tested for if pPicture is used immediately after. Some comments would have been nice!

[Leon Weber (leonn)]

Unfortunately, replacing
  DrawablePtr pDrawable = pPicture->pDrawable;
with
  DrawablePtr pDrawable = pPicturePrivate->pDrawable;

does not help, it doesn't even compile:

libtool: compile: i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../include -I../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -O2 -march=nocona -pipe -MT cw_render.lo -MD -MP -MF .deps/cw_render.Tpo -c cw_render.c -fPIC -DPIC -o .libs/cw_render.o
cw_render.c: In function ‘cwGetBackingPicture’:
cw_render.c:124: error: ‘struct <anonymous>’ has no member named ‘pDrawable’
make[2]: *** [cw_render.lo] Error 1