finding source of segfault

[Drew Parsons]

On Thu, 2006-06-15 at 13:47 -0400, Adam Jackson wrote:
> On Wednesday 14 June 2006 21:55, Drew Parsons wrote:
> > On Wed, 2006-06-14 at 11:02 -0400, Adam Jackson wrote:
> > > 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.
> 
> So you're warned, that's likely to be non-trivial.  The postscript backend 
> tries really hard to be vector-only; if you ever hit fb rasterisation you'll 
> have to flatten out all the postscript you already received first, and then 
> continue to render the rest of the job in fb only.
> 

Ah, ok.  It'll probably be beyond me in that case. In it probably needs
to be that way - postscript ought to be vector-only. But I'll have a
look, maybe your idea of the stub implementation will work best.

Drew