finding source of segfault
dparsons at debian.org
Tue Jun 27 21:44:30 PDT 2006
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
> if ( pScreen->SetWindowPixmap && pScreen->GetWindowPixmap )
> (*pScreen->SetWindowPixmap) (pWin, (*pScreen->GetWindowPixmap)
I've logged this issue with the patch on bugzilla #7346,
More information about the xorg