Bug 12414 - Bad pixmap at XAADestroyPixmap (created at fb24_32ReformatTile)
Summary: Bad pixmap at XAADestroyPixmap (created at fb24_32ReformatTile)
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/DDX/Xorg (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Depends on:
Blocks: xorg-7.4
  Show dependency treegraph
Reported: 2007-09-13 13:18 UTC by Paulo César Pereira de Andrade
Modified: 2008-06-20 10:32 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Paulo César Pereira de Andrade 2007-09-13 13:18:11 UTC
This bug may happen with some KDE applications, but happens for sure with superkaramba. Note that it is not by using any feature of superkaramba, but, by using WindowMaker and double clicking on superkaramba's title bar to "shade" it.

  I checked all dix/pixmap.c:AllocatePixmap() and all of them are apparently correctly wrapped. And only one non wrapped call happens, and only one call to fb24_32ReformatTile exists until the crash, and the GC's replaced tile.pixmap is the crash cause.

backtrace of the fb24_32ReformatTile call:
(gdb) bt
#0  fb24_32ReformatTile (pOldTile=0x8402038, bitsPerPixel=32) at fb24_32.c:566
#1  0xb7abbd82 in fbValidateGC (pGC=0x83f63b8, changes=13568, pDrawable=0x842e2e0) at fbgc.c:240
#2  0x081444d1 in miBSCheapValidateGC (pGC=0x83f63b8, stateChanges=13568, pDrawable=0x842e2e0) at mibstore.c:808
#3  0xb7a4254f in XAAValidateGC (pGC=0x83f63b8, changes=13568, pDraw=0x842e2e0) at xaaGC.c:73
#4  0x081bfd1c in cwValidateGC (pGC=0x83f63b8, stateChanges=13568, pDrawable=0x842e2e0) at cw.c:166
#5  0x081ba7b6 in damageValidateGC (pGC=0x83f63b8, changes=13568, pDrawable=0x842e2e0) at damage.c:445
#6  0x080a1a27 in ValidateGC (pDraw=0x842e2e0, pGC=0x83f63b8) at gc.c:77
#7  0x081bffbd in cwValidateGC (pGC=0x8414578, stateChanges=13568, pDrawable=0x83cd438) at cw.c:234
#8  0x081ba7b6 in damageValidateGC (pGC=0x8414578, changes=13568, pDrawable=0x83cd438) at damage.c:445
#9  0x080a1a27 in ValidateGC (pDraw=0x83cd438, pGC=0x8414578) at gc.c:77
#10 0x0808b969 in ProcPolyFillRectangle (client=0x82c0040) at dispatch.c:1950
#11 0x0818cd67 in XaceCatchDispatchProc (client=0x82c0040) at xace.c:281
#12 0x080871e9 in Dispatch () at dispatch.c:457
#13 0x08070cc9 in main (argc=6, argv=0xbf9c5a44, envp=0xbf9c5a60) at main.c:445

This should also be helpful:
fbValidateGC (pGC=0x83f63b8, changes=13568, pDrawable=0x842e2e0) at fbgc.c:242
242                 if (pNewTile)
244                     fbGetRotatedPixmap(pGC) = pOldTile;
245                     pGC->tile.pixmap = pNewTile;
246                     changes |= GCTile;
(gdb) p pNewTile
$16 = (PixmapPtr) 0x83e9300
(gdb) p *pNewTile
$17 = {drawable = {type = 1 '\001', class = 0 '\0', depth = 16 '\020', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0,
    width = 10, height = 24, pScreen = 0x828e160, serialNumber = 2454}, refcnt = 1, devKind = 40, devPrivate = {
    ptr = 0x83e9358, val = 138318680, uval = 138318680, fptr = 0x83e9358}, devPrivates = 0x83e932c, screen_x = 0, screen_y = 0}
(gdb) p pOldTile
$18 = (PixmapPtr) 0x8402038
(gdb) p *pOldTile
$19 = {drawable = {type = 1 '\001', class = 0 '\0', depth = 16 '\020', bitsPerPixel = 16 '\020', id = 16777321, x = 0, y = 0,
    width = 10, height = 24, pScreen = 0x828e160, serialNumber = 1705}, refcnt = 6, devKind = 20, devPrivate = {
    ptr = 0x8402090, val = 138420368, uval = 138420368, fptr = 0x8402090}, devPrivates = 0x8402064, screen_x = 0, screen_y = 0}

and the crash:
Program received signal SIGSEGV, Segmentation fault.
0xb7a41d9a in XAADestroyPixmap (pPix=0x83e9300) at xaaInit.c:630
630                     while(pLink->pPix != pPix) {

at "this" crash pLink turned to NULL, but it can crash in different ways, because pPriv points to bad memory and the "flags" field is 'junk'. Note that it is calling XAADestroyPixmap to free pixmap at address 0x83e9300 (that was created at fb24_32ReformatTile but not wrapped at XAACreatePixmap).

The video driver is radeon, at 16 bpp and sources are xorg-1.3.0. The problem doesn't happen under the KDE window manager, but I believe it isn't WindowMaker's fault here.

I can try to fix this problem by myself for Mandriva's distro, but if someone can give a better hint as to what is causing this, or even better, a solution to the problem, i.e. why it seens to be following a code path it shouldn't, it would be better.
Comment 1 Paulo César Pereira de Andrade 2008-02-25 09:08:33 UTC
  Just to add some more information that may be useful.

  The problem with WindowMaker was when Composite was enabled and not having
a root window of depth 24.

  I made a small patch for WindowMaker so that it will always use the default
visual unless the "-visualid" command line option was specified. This way it
will not choose the "best" visual, i.e. use the a8r8g8b8 visual added at
composite extension initialization.

  But the problem described on this bug report already did not happen anymore
since switching to server-1.4-branch.

  I believe there may exist other cases where applications that are not
aware of render/composite may show problems. But I believe developers are
already aware of it.

  The patch I made for WindowMaker also fixed all the screen corruption I
had been experiencing, i.e. popup menus background restoring at weird
offsets, windows contents restoring at "wrong" stacking order, etc.
Comment 2 Adam Jackson 2008-03-24 09:41:36 UTC
This isn't fixed, you just worked around it on the client side.
Comment 3 Adam Jackson 2008-06-20 10:32:41 UTC
fb24_32ReformatTile() now calls the screen's CreatePixmap method, so XAA should no longer get confused like this.

I think there's still something subtle happening here, since a 16+32 pixmap should be impossible.  But closing anyway, we'll keep an eye out for it.

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.