finding source of segfault

[Drew Parsons]

On Mon, 2006-06-19 at 11:09 +1000, Drew Parsons wrote:
> On Wed, 2006-06-14 at 11:02 -0400, Adam Jackson wrote:
> > On Wednesday 14 June 2006 01:34, Drew Parsons wrote:
> > 
> > > I'm writing now on the off-chance that someone might recognise the
> > > signature of the segfault and be able to pinpoint  which lib needs to be
> > > upgraded to X11R7.1 (or beyond).  The backtrace looks like:
> > >
> > > #0  0x00000000 in ?? ()
> > > #1  0x080bc2ee in compCreateWindow (pWin=0x875e6e8) at compwindow.c:600
> > 
> > This sort of signature typically means you attempted to call through a 
> > function pointer that was set to NULL.  compCreateWindow calls through three 
> > of the screen's function pointer chains: CreateWindow, GetWindowPixmap, and 
> > SetWindowPixmap.
> > 
...
> > Right now those chains are only ever called from the Damage and Composite 
> > extensions, so the minimal hack might be to just always disable those in 
> > Xprt; I had thought this was done already though.  The better solution might 
> > be to add stub implementations to the postscript backend and see what breaks.  
> > Since the ps backend clearly believes it can implement the world without 
> > using fb, it might be fine to just have those calls no-op.
> > 

> Anyway, looking at it, it seems to me the simplest solution is just to
> check GetWindowPixmap and SetWindowPixmap are not null in compwindow.c.
> There is precedent for this approach in miext/damage/damage.c, l.85.
> Doing this also adds a modicum of flexibility to composite, in case some
> other backend driver later on decides in a similar way to be more vector
> based and not need WindowPixmap.
> 
> My patch would be to replace l.600 in composite/compwindow.c 
> 
> to
> 
> if ( pScreen->SetWindowPixmap && pScreen->GetWindowPixmap )
> 	(*pScreen->SetWindowPixmap) (pWin, (*pScreen->GetWindowPixmap)
> (pWin->parent));
> 

I've logged this issue with the patch on bugzilla #7346,
https://bugs.freedesktop.org/show_bug.cgi?id=7346

Thanks,

Drew