| Summary: | Bad pixmap at XAADestroyPixmap (created at fb24_32ReformatTile) | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Paulo César Pereira de Andrade <pcpa> |
| Component: | Server/DDX/Xorg | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 10101 | ||
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. This isn't fixed, you just worked around it on the client side. 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.
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) (gdb) 244 fbGetRotatedPixmap(pGC) = pOldTile; (gdb) 245 pGC->tile.pixmap = pNewTile; (gdb) 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.