finding source of segfault
dparsons at debian.org
Wed Jun 14 18:55:11 PDT 2006
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
> 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,
More information about the xorg