The following files crash on my Windows 7 build with the command line: gswin32c -Z: -r600 -sDEVICE=ppmraw -o nul: -dBandHeight=128 _____ where ____ is the file similarly, all except fts_31_3120.pdf fail with Segmentation fault on peeves (linux i7) with the command line: bin/gs -Z: -r600 -sDEVICE=ppmraw -o nul: -dBandHeight=128 _____ The file list is: fts_17_1701.pdf fts_17_1703.pdf fts_17_1705.pdf fts_17_1707.pdf fts_23_2300.pdf fts_31_3107.pdf fts_31_3120.pdf I think these are all related. On Windows I looked at 3107 and was able to get repeatable failures in device_clist_reloc_ptrs when trying to RELOC the icc_table. There is a suspicious comment in gxclist.c: /* Where is the GC information for the common objects that are shared between the reader and writer. I see pointers in there, but they don't seem to be GC. This is why I have put the icc_table and the link cache in the reader and the writer rather than the common. fixme: Also, if icc_cache_cl is not included in the writer, 64bit builds will seg fault */ Thus I am assigning to Michael (apologies in advance) since it looks like it is related to the ICC changes. NOTE: I am available for discussion on this issue.
I am able to replicate the problem even with my changes of moving the device profile to the device and removing all profiles from GC for the file fts_31_3120.pdf in win32 at 300dpi when going to ppmraw. A difference though is that my crash occurs at the relocation of cdev->writer.pinst not the icc table. Digging more into this.
I re-ran the tests on Windows and peeves for the cited files. Some files that used to fail now work -- possibly due to my pattern-clist related change (rev 11613). The files that now fail on Windows are: fts_17_1705.pdf fts_23_2303.pdf fts_31_3120.pdf and on peeves, 2303 works
With a debug build, I am able to see 'Object not in any chunk' and it is coming from the enumeration of a clist_device with dname of 'pattern-clist'. I can see this with 1704, but it is probably the same for the other files. This may be due to the 'ymin' being -1 when it should be 0 or greater, so the ENUM procs are attempting to enumerate clist_device elements that are particular to the 'writer'. We need to make sure that the pattern-clist gets switched over to 'reader' mode once writing is complete. Since I can duplicate this in customer 532 code, I will be digging into this as well. Michael, if you want to give it to me, that's fine. If not, maybe we will work on this together, and keep each other posted.
The pattern-clist devices created during the clist playback for the the page printing were never freed, even though they were closed and some of their info was invalid. This seems to cure the segfault with 3120, but I am still seeing a segfault in 1705. The (partial) patch that fixes 3120 for me is: Index: base/gxpcmap.c =================================================================== --- base/gxpcmap.c (revision 11614) +++ base/gxpcmap.c (working copy) @@ -727,6 +727,7 @@ ctile->cdev->common.memory); rc_decrement(ctile->cdev->common.icc_cache_cl, "gx_pattern_cache_free_entry"); + gs_free_object(ctile->cdev->common.memory, ctile->cdev, "free_pattern_cache_entry(pattern-clist)"); ctile->cdev = NULL; } Note that this eliminates the 'object not in any chunk' messages I was seeing with a debug build. Still a work in progress...
Closing after split into two different bugs. Bug 691549 and Bug 691550 *** This bug has been marked as a duplicate of bug 691549 ***