David Dawes
dawes****@XFree*****
2003年 8月 15日 (金) 08:10:24 JST
On Thu, Aug 14, 2003 at 02:59:50PM -0700, Mark Vojkovich wrote: >On Thu, 14 Aug 2003, David Dawes wrote: > >> On Thu, Aug 14, 2003 at 09:32:40PM +0900, Chisato Yamauchi wrote: >> >From: David Dawes <dawes****@XFree*****> >> >Subject: Re: (patch seq: 5752) A patch for preventing XAA crash >> >Date: Wed, 13 Aug 2003 21:41:28 -0400 >> >Message-ID: <20030****@xfree*****> >> > >> >> Could you get some more information from XAACacheTile() that might show >> >> why pCache is NULL? >> > >> > We did not find the reason. >> > >> >> The values of size and the pCachePriv fields that get used might help. >> > >> > Here is "crash.log" and modified xaaPCache.c. >> > >> > http://www.mozilla.gr.jp/~kazhik/tmp/ >> > >> > This is one of the results investigated by Kazuhiko. >> >There may be something help in it. >> >> Thanks for the detailed log! It shows what I thought might be happening -- >> the number of cache slots being zero for the type of slot chosen: >> >> XAAInitPixmapCache; FreePixmapCachePrivate >> Num256++; 1 >> Num256++; 2 >> Num256++; 3 >> Num256--; 2 >> Num256--; 1 >> Num256--; 0 >> XAACacheTile() >> [1] *current: 0; max: 0; pCache: 0; w: c8; h: c8; size: c8 >> [2] *current: 1; max: 0; pCache: 0 >> >> >> Since it is possible for zero slots of a particular type to be available, >> the XAACache* functions need to be able to handle this. Returning >> the NULL value in that case, and checking for it looks reasonable >> to me, but Mark might have a better idea. Whatever the best solution >> is, it looks like it will need to be applied to other places too. >> > > XAACacheTile() should have never been called if no slots existed. >MaxCacheableTileWidth and MaxCacheableTileHeight should have been >consulted at some point. OK, we need to see what those values are at this point. XAAPaintWindow(), where the crash is apparently happening, does have a test for them, so maybe there's getting set incorrectly somewhere. if(infoRec->UsingPixmapCache && infoRec->FillCacheBltRects && !NoCache && ((what == PW_BORDER) || (pPix->drawable.height != pWin->drawable.height) || (pPix->drawable.width != pWin->drawable.width)) && (pPix->drawable.height <= infoRec->MaxCacheableTileHeight) && (pPix->drawable.width <= infoRec->MaxCacheableTileWidth)) { XAACacheInfoPtr pCache = (*infoRec->CacheTile)(infoRec->pScrn, pPix); (*infoRec->FillCacheBltRects)(infoRec->pScrn, GXcopy, ~0, nBox, pBox, xorg, yorg, pCache); return; } This check assumes that if there are no 256x256 slots there won't be any 512x512 slots. I'm not 100% sure if it can ever happen that there are 512x512 slots but no 256x256 slots. If the debugging could be extended to print both infoRec->MaxCacheableTileHeight and Num512, it should clarify if this is the problem or not. > If there is really an XAA bug here, how come nobody has seen >this before? It might be a corner case that hasn't been hit before. I guess it's also possible that it's a compiler optimisation problem. We need to finish tracing it back before coming to any final conclusions. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes
