Bug 10617 - Xorg crashes when retracting yakuake on certain conditions.
Summary: Xorg crashes when retracting yakuake on certain conditions.
Status: RESOLVED WORKSFORME
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: 7.2 (2007.02)
Hardware: x86 (IA32) Linux (All)
: high blocker
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard: 2011BRB_Reviewed
Keywords: have-backtrace
Depends on:
Blocks:
 
Reported: 2007-04-11 15:29 UTC by Raúl
Modified: 2011-10-21 11:04 UTC (History)
15 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg log for the crash. (41.01 KB, text/plain)
2007-04-11 15:33 UTC, Raúl
no flags Details
Xorg configuration file (3.84 KB, text/plain)
2007-04-11 15:37 UTC, Raúl
no flags Details
Xorg log for the crash with debugging package installed. (40.81 KB, text/plain)
2007-04-12 01:01 UTC, Raúl
no flags Details
Freshes Xorg log (with 1.3 version of the protocol) (88.04 KB, text/plain)
2007-08-11 04:15 UTC, Raúl
no flags Details

Description Raúl 2007-04-11 15:29:52 UTC
I use yakuake (a nice terminal emulator) on kde, when you are not using it, it hides on the upper part of your screen. If you press F12, then yakuake slides down and you use it, press F12 again and it slides up to hide.

If when you use yakuake with some app that outputs to the console on its own(e.g.: no user interaction) and you force hiding yakuake using F12, Xorg wil crash at a certain moment.

What I do to repeat the crash:
- F12 to bring yakuake down.
- Launch aptitude (debian text package manager)
- Press u in aptitude so package list updates (you may be root for this)
- Aptitude starts updating the console, bringing nice coloured bars.
- Press several times F12 to force yakuake to hide and slow, sliding.
- X will crash.

I use aptitude because it reproduces quite well the behaviour to make X crash, but I guess anything just showing nice colors and scrollbars on its own will make X crash.

I use Xorg 7.2 and intel driver 1.9.94 on a 2.6.20.4 linux kernel. I also attach the Xorg.log and this are the relevant log lines for the backtrace:

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x84) [0x80c2074]
1: [0xb7fd4420]
2: /usr/bin/X [0x8172e4c]
3: /usr/bin/X [0x816f325]
4: /usr/bin/X(CompositeGlyphs+0x9a) [0x815588a]
5: /usr/bin/X [0x815d468]
6: /usr/bin/X [0x8158915]
7: /usr/bin/X [0x814bd0e]
8: /usr/bin/X(Dispatch+0x1ab) [0x80883cb]
9: /usr/bin/X(main+0x489) [0x80701f9]
10: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xc8) [0xb7df2ea8]
11: /usr/bin/X(FontFileCompleteXLFD+0xa9) [0x806f531]

Fatal server error:
Caught signal 11.  Server aborting
Comment 1 Raúl 2007-04-11 15:33:50 UTC
Created attachment 9569 [details]
Xorg log for the crash.
Comment 2 Raúl 2007-04-11 15:37:11 UTC
Created attachment 9570 [details]
Xorg configuration file
Comment 3 Raúl 2007-04-11 15:40:40 UTC
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)
Comment 4 Michel Dänzer 2007-04-11 23:27:48 UTC
Can you get a log file (or even better, a gdb backtrace) with the xserver-xorg-core-dbg package installed?
Comment 5 Raúl 2007-04-12 01:00:29 UTC
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.
Comment 6 Raúl 2007-04-12 01:01:26 UTC
Created attachment 9575 [details]
Xorg log for the crash with debugging package installed.
Comment 7 Raúl 2007-04-15 16:07:57 UTC
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
Comment 8 Raúl 2007-05-21 15:51:16 UTC
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) 0x824c470

Now into frame #8:
#8  0x08172442 in cwGetBackingPicture (pPicture=0x91c1ef0, x_off=0xbfa25a90,
    y_off=0xbfa25a8c) at ../../../miext/cw/cw_render.c:129
129     in ../../../miext/cw/cw_render.c

p *pPicture
$1 = {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}

cwPictureIndex=0
p pPicture->devPrivates[0].ptr
$3 = (pointer) 0x976c298 (cwPicturePtr pPicturePrivate)
p *(WindowPtr)pPicture->pDrawable
$17 = {drawable = {type = 0 '\0', class = 1 '\001', depth = 24 '\030',
    bitsPerPixel = 32 ' ', id = 35672184, x = 1, y = 0, width = 1022,
    height = 342, pScreen = 0x8216e18, serialNumber = 4021270},
  parent = 0x95937e0, nextSib = 0x0, prevSib = 0x0, firstChild = 0x8f26c38,
  lastChild = 0x8f26c38, clipList = {extents = {x1 = 1, y1 = 0, x2 = 1,
      y2 = 0}, data = 0x81edf04}, borderClip = {extents = {x1 = 1, y1 = 0,
      x2 = 1, y2 = 0}, data = 0x81edf04}, valdata = 0x0, winSize = {extents = {
      x1 = 1, y1 = 0, x2 = 1023, y2 = 22}, data = 0x84feb08}, borderSize = {
    extents = {x1 = 1, y1 = 0, x2 = 1023, y2 = 22}, data = 0x8f193d0},
  origin = {x = 0, y = 0}, borderWidth = 0, deliverableEvents = 57471,
  eventMask = 6479999, background = {pixmap = 0xa7c03008, pixel = 2814390280},
  border = {pixmap = 0xff000000, pixel = 4278190080}, backStorage = 0x0,
  optional = 0x911f7d8, backgroundState = 3, borderIsPixel = 1,
  cursorIsNone = 0, backingStore = 0, saveUnder = 0, DIXsaveUnder = 0,
  bitGravity = 1, winGravity = 1, overrideRedirect = 0, visibility = 3,
  mapped = 1, realized = 0, viewable = 0, dontPropagate = 0, forcedBS = 0,
  redirectDraw = 0, devPrivates = 0x8f26dec}

cwWindowIndex=3
p *pPicture->pDrawable
$5 = {type = 0 '\0', class = 1 '\001', depth = 24 '\030',
  bitsPerPixel = 32 ' ', id = 35672184, x = 1, y = 0, width = 1022,
  height = 342, pScreen = 0x8216e18, serialNumber = 4021270}

(gdb) p ((WindowPtr)pPicture->pDrawable)->devPrivates[3]
$13 = {ptr = 0x0, val = 0, uval = 0, fptr = 0}
(gdb) p ((WindowPtr)pPicture->pDrawable)->devPrivates[2]
$14 = {ptr = 0x0, val = 0, uval = 0, fptr = 0}
(gdb) p ((WindowPtr)pPicture->pDrawable)->devPrivates[1]
$15 = {ptr = 0x91c1ef0, val = 152837872, uval = 152837872, fptr = 0x91c1ef0}
(gdb) p ((WindowPtr)pPicture->pDrawable)->devPrivates[0]
$16 = {ptr = 0x8260758, val = 136709976, uval = 136709976, fptr = 0x8260758}

It seems that ((WindowPtr)pPicture->pDrawable)->devPrivates[3] points nowhere when it should, but unfortunately I don't know the reason of this. If you miss any information please let me know, also I could send the backtrace if you tell me how I should send it (96MB uncompressed, 10MB bzipped) so I think asking me for a certain value is more convenient.
Comment 9 Michał Woźniak 2007-07-02 10:49:25 UTC
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
Comment 10 Jesse Barnes 2007-08-09 10:45:46 UTC
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?
Comment 11 Raúl 2007-08-11 04:13:15 UTC
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.
Comment 12 Raúl 2007-08-11 04:15:01 UTC
Created attachment 11091 [details]
Freshes Xorg log (with 1.3 version of the protocol)
Comment 13 Evil 2007-10-25 04:45:12 UTC
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.
Comment 14 Kelvie Wong 2007-11-11 12:04:15 UTC
(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.
Comment 15 Kelvie Wong 2007-11-11 13:06:23 UTC
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.
Comment 16 MarSarK 2007-11-16 07:01:58 UTC
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.
Comment 17 Marcel Partap 2007-11-18 03:42:20 UTC
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?
Comment 18 Brice Goglin 2007-11-27 14:28:04 UTC
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
Comment 19 Matthias Berndt 2008-01-20 11:43:47 UTC
So, how is this coming along?
Comment 20 Abhinay Mukunthan 2008-03-17 02:46:16 UTC
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
Comment 21 samg 2008-06-11 12:16:51 UTC
(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.
Comment 22 Robie Basak 2008-07-18 13:43:53 UTC
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}
Comment 23 Robie Basak 2008-07-22 10:54:33 UTC
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!
Comment 24 Leon Weber 2008-11-17 08:08:04 UTC
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

Comment 25 Jeremy Huddleston Sequoia 2011-10-11 01:10:32 UTC
Is this still an issue?
Comment 26 Raúl 2011-10-19 11:21:31 UTC
The system where I experienced this bug is running quite an old version version of graphics stack. Thus, I can't provide further testing results.

On my new system I can't reproduce this bug, but this system is totally different.

I propose closing this bug unless anyone is able to reproduce with a recent version of the graphics stack.

Regards,
Comment 27 Jeremy Huddleston Sequoia 2011-10-21 11:04:23 UTC
Thanks.


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.