Summary: | SEGV with transparent patterns in patterns | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Robin Watts <robin.watts> |
Component: | Graphics Library | Assignee: | Michael Vrhel <michael.vrhel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P4 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | All | ||
Customer: | Word Size: | --- | |
Attachments: |
xps6.pdf
0001.patch |
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. |
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.