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!

Xprint is an interesting piece of work, no? ;)

> 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.

OK, I'll focus on Xprint/ps and see what I can dig up.  I'll want to try
to figure out why the segfault's only happening now, find what changed
since I last tested CVS.  I might think about drawing ps back to the fb
fold, if I can manage it.

Thanks for the tips,

Drew