Created attachment 7521 [details] xps6.pdf The following command gives a SEGV on both windows and linux: gs/debugbin/gswin32c.exe -o out.ppm -sDEVICE=ppmraw -r72 xps6.pdf I've reduced the file (originally given from pdfwriting an xps file) as much as possible. It now has a page with a rectangle painted in pattern #1. Pattern #1 has no painting operations, but does set it's colorspace to Pattern #2. Pattern #2 has no painting operations at all, not even to set it's colorspace. Pattern #2 DOES have a transparent colorspace (constant 50% alpha) declared in the ExtGState dictionary though, which leads me to suspect that we are deciding that Pattern #2 must be transparent.
I have a patch that allows this to run to completion with plausible rendering. I think that there are 2 problems here. Firstly when run with -Z@? to fill allocated memory with a known pattern, it dies with an out of memory error due to a calculation being based on uninitialised memory. It seems that a pattern tile caches transbuff structure is being allocated, but the number of channels is not being set. For some reason (possibly because no colorspace is set/drawing operations are done) a memory allocation is done based upon 'n_chan' which is set to a1a1a1a1 - and hence the program fails to allocate and dies. If we get past this, then later on, the pdf14 device is popped before anyone writes to the tile and a blend operation is done which SEGVs due to one of the data planes being an uninitialised one. The patch attached sets n_chan to zero at allocation time. This solves the allocation problem. We add a check for n_chan being zero into the blending routine too. This allows the file to complete, but I'm really not sure it's the correct solution - this could well be patching the symptom, not being a proper cure. Left here for comments from MJV.
Created attachment 7523 [details] 0001.patch This is a git format patch. To apply it, do: git am 0001.patch That will make a new commit consisting of just that patch on the end of your current branch. This means you can test/poke/prod it and then get rid of it easily. I assume tortoise git has the same kind of thing.
Assigning to Michael for his opinion.
Patch makes sense and has been committed. Closing bug.