Hi, just writing down what I just said on IRC:
Ferenc Wagner <[email protected]> (03/05/2011): > #7 0x080a2b11 in OsSigHandler (signo=11, sip=0xbfebed8c, unused=0xbfebee0c) > at ../../os/osinit.c:156 > No locals. > #8 <signal handler called> > No symbol table info available. > #9 LookupClientResourceComplex (client=0x983b4e8, type=268435491, > func=0x80f5d00 <XineramaFindIDByScrnum>, cdata=0xbfebf164) at > ../../dix/resource.c:714 > resources = 0xa32cee0 > this = 0x30 > next = 0x30 > value = <value optimized out> > i = 954 > #10 0x080f8203 in PanoramiXFindIDByScrnum (type=954, id=1096817571, screen=1) > at ../../Xext/panoramiX.c:365 > data = {screen = 1, id = 1096817571} > val = 0xbfebf1bc After a very quick look, could be a “following an invalid next pointer” case as mentioned in: | commit 6d7ba5e0fcb5d1bce6bb213dec009f3a0f802d26 | Author: Kristian Høgsberg <[email protected]> | Date: Sat May 1 13:07:46 2010 -0400 | | dix: Update element count in FreeResource*() | | FreeResource() keeps clientTable[cid].elements up to date with the | number of resources allocated to the client. The other free | resource functions (FreeResourceByType(), | FreeClientNeverRetainResources() and FreeClientResources()) don't | maintain this invariant. | | Typically, the only consequence is that the element count is too high | and we end up allocating the hash table bigger than necessary. However, | FreeResource() also relies on the element count to restart the search if | the list of resources has been changed during a resource destruction | callback. Since FreeResourceByType() doesn't update the count, if we call | that from a resource destruction callback from FreeResource(), the | loop isn't restarted and we end up following an invalid next pointer. | | Furthermore, LookupClientResourceComplex() and | FreeClientNeverRetainResources() don't use the element count to detect | if a callback deleted a resource and may end up following an invalid | next pointer if the resource system is called into recursively. | | Signed-off-by: Kristian Høgsberg <[email protected]> | Reviewed-by: Keith Packard <[email protected]> This patch can trivially be cherry-picked on top of the debian-squeeze branch, I'll try and provide you with a package for i386 with that patch included. I'll try and look at other resource-related fixes later on, as well as what happened to the callers (frames #11 and higher). Mraw, KiBi.
signature.asc
Description: Digital signature
