finding source of segfault

[Drew Parsons]

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.
> 
> Line 600 of compwindow.c calls both the GetWindowPixmap and SetWindowPixmap 
> chains.  These are normally always provided by fb, but while Xprint's raster 
> and pcl backends wrap fb, the postscript backend does not, and does not 
> itself provide implementations for those chains.  Woo!
> 
> 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.
> 

It does seem a bit strange the problem is only appearing now. I can't
see any changes in Xprint in regards to GetWindowPixmap (I can't see any
handling for it there in the old code). The only thing I can think that
might have affected it was when you converted the Xprint drivers from
cfb to fb in April.

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 from 

(*pScreen->SetWindowPixmap) (pWin, (*pScreen->GetWindowPixmap)
(pWin->parent));

to

if ( pScreen->SetWindowPixmap && pScreen->GetWindowPixmap )
	(*pScreen->SetWindowPixmap) (pWin, (*pScreen->GetWindowPixmap)
(pWin->parent));


With that small patch, Xprint is back in action.

Do you think this a good way to deal with it?

Drew