Re: (patch seq: 5752) A patch for preventing XAA crash (X-tt-list:101) - After X-TT Project

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

After X-TT Project

[X-tt-list:101] Re: (patch seq: 5752) A patch for preventing XAA crash