Created attachment 9569 [details]
Xorg log for the crash.

Created attachment 9570 [details]
Xorg configuration file

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)

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

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.

Created attachment 9575 [details]
Xorg log for the crash with debugging package installed.

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

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.

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

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?

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.

Created attachment 11091 [details]
Freshes Xorg log (with 1.3 version of the protocol)

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.

(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.

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.

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.

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?

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

So, how is this coming along?

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

(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.

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}

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!

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

Is this still an issue?

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,

Thanks.