The customer reports and I've verified that the PDF file Panneau1.pdf causes both gs8.61 and gshead (r8410) to seg fault. The command line I'm using: bin/gs -sDEVICE=tiffsep -sOutputFile=a.tif -r30 ./Panneau1.pdf Panneau1.pdf is very large and can be found on casper in /home/support/689581 Apple Preview and Adobe Acrobat Reader open the file without problem, as does Ghostscript 8.54. I'm searching for the responsible revision now.
Then answer to the responsible revision was hard to find, since this issue has come and gone several times. The bad news is that these changes don't appear to be relevant to the problem, so it's possibly a memory corruption issue. . . . r6557 - works r6558 - seg fault . . . r6842 - seg faults r6843 - works . . . r8055 - works r8056 - make fails r8057 - make fails r8058 - make fails r8059 - floating exception . . .
Valgrind reports: Invalid read of size 4 at 0x814AA5A: search_compressed_color_list (gdevdevn.c:987) by 0x814AE38: devn_encode_compressed_color (gdevdevn.c:1210) by 0x8143AF7: pdf14_compressed_encode_color (gdevp14.c:995) by 0x8146AE4: pdf14_cmap_cmyk_direct (gdevp14.c:2551) by 0x831C955: gx_remap_DeviceCMYK (gxcmap.c:838) by 0x812679B: patch_color_to_device_color_inline (gxshade6.c:946) by 0x811D88E: decompose_linear_color (gxshade6.c:1060) by 0x811E963: mesh_padding (gxshade6.c:1939) by 0x811EC38: fill_wedges_aux (gxshade6.c:2030) by 0x811EB83: fill_wedges_aux (gxshade6.c:2021) by 0x811EB83: fill_wedges_aux (gxshade6.c:2021) by 0x811ED1F: fill_wedges (gxshade6.c:2059) Address 0x477BCF4 is 60 bytes inside a block of size 23,564 free'd at 0x401C4FE: free (vg_replace_malloc.c:233) by 0x830339B: gs_heap_free_object (gsmalloc.c:342) by 0x82E6C7A: alloc_free_chunk (gsalloc.c:1824) by 0x82E535B: i_free_object (gsalloc.c:814) by 0x81BDB82: clist_image_end_image (gxclimag.c:846) by 0x8337594: gx_image_end (gximage.c:209) by 0x82FE424: gs_image_cleanup (gsimage.c:632) by 0x82FE453: gs_image_cleanup_and_free_enum (gsimage.c:643) by 0x80EBBEF: image_cleanup (zimage.c:587) by 0x80EBAB3: image_file_continue (zimage.c:535) by 0x80C3B54: call_operator (interp.c:111) by 0x80C5467: interp (interp.c:1158) Apparently, compressed_color_list is freed prematurely. This happens regardless of -dNOGC flag.
I guess this is either a shading or color issue. Start with Leo and shading.
Can't find the test file. Assigning to thye bug author.
This looks to be related to the issue #689581. In that report, the customer noted that when they run the file in a release build, they must 'disable colour compression' or they experience a crash. This only happens with tiffsep (tiff32nc is fine). As this bug is reported against tiffsep, and seems to be related to colour compression, perhaps the two are the same issue. Note that the crash with the file for #689581 does not occur for me under a debugger, which makes me suspect memory corruption. The incorrect output problem also noted in that report has been fixed separately by the customer. I originally suspected the two manifestations to be the same root cause, this was incorrect, there are two different problems. The file for 689581 is available, and is (I think) probably smaller than the file for this report.
Doh! please read the number #689581 in my previous comment to be #689895. Sorry....
The test file is on casper, in the directory /home/support/689581
Can't reproduce with HEAD. From Comment #2 I conclude that the problem is incorrect data in the field ((* ((*pfs).dev)).color_info).separable_and_linear when patch_color_to_device_color_inline is called. Since pdf14_compressed_encode_color is called, separable_and_linear must be not equal to GX_CINFO_SEP_LIN. If so is_linear_color_applicable returns false, and as consequence patch_color_to_device_color_inline would not be called. The device is pdf14_clist_CMYKspot_device (that is only device that provides pdf14_compressed_encode_color). Thus the Comment #2 stack snapshot was obtained with an incorrect separate_and_linear flag for pdf14_clist_CMYKspot_device. I recall we have had a bug of this kind few monthes ago, and I passed it to a color group (possibly to Ralph) with a similar analysis. Likely pdf14_clist_CMYKspot_device needs a similar fix. Tracing the test case with C debugger, I see that shading is never called with a transparency compositor. Thus the current HEAD never falls into the situation, in which the problem can appear. I'm unclear why so happens - possibly something had changed for transparency in gs/Resource/Init so now it goes by a different way. I'm returning this bug to Support because it needs a clarification : 1. Is it reproducible with HEAD ? 2. Why in the past the shading happened with transparency and doesn't happen now ? Likely need to find out what is the *newest* failing revision and what was changed after it ? Note the tool for locating revisions searches for the *oldest* failing revision, and does it imprecisely. Possiblty the tool needs an improvement for this bug. 3. Why pdf14_clist_CMYKspot_device provided an incorrect separate_and_linear and whether it is still incorrect or not. It should be passed to the color group. In any case I dodn't see a problem with shading code here.
The customer did some additional testing: The problem seems to be in the relocation of the devn_params.compressed_color_list by the PDF14 device. You see that very clearly when you run GS under valgrind. The typical message is: ==23011== Invalid read of size 4 ==23011== at 0x8143F8C: search_compressed_color_list (gdevdevn.c:987) ==23011== by 0x8144382: devn_encode_compressed_color (gdevdevn.c:1210) ==23011== by 0x813D44D: pdf14_compressed_encode_color (gdevp14.c:1071) ==23011== by 0x8140023: pdf14_cmap_gray_direct (gdevp14.c:2586) ==23011== by 0x83054E8: gx_remap_DeviceGray (gxcmap.c:770) ... ==23011== Address 0x680f424 is 60 bytes inside a block of size 6,208 free'd ==23011== at 0x402165C: free (vg_replace_malloc.c:323) ==23011== by 0x82ED88F: gs_heap_free_object (gsmalloc.c:504) ==23011== by 0x82D22CB: alloc_free_chunk (gsalloc.c:1824) ==23011== by 0x80E94FD: gc_free_empty_chunks (igc.c:1352) ==23011== by 0x80E7CDF: gs_gc_reclaim (igc.c:483) ==23011== by 0x8161351: context_reclaim (zcontext.c:283) ==23011== by 0x80C3E97: gs_vmreclaim (ireclaim.c:153) ... So first I tried to find what was going wrong with the relocation, but since I absolutely don't know how the GC works, I didn't go far. So I tried something else: I removed the struct compressed_color_list_t from the GC system, and used malloc/free instead to allocate/deallocate it. And that seems to work: it solves the problem in all the test cases I have, both in my version of GS and with 8.63. I attach the diff. I have also a new file making the problem easier to reproduce. With this one I have a systematic crash with my version, with GS8.62, and with GS 8.63 (Linux and Mac). The file is here: --redacted since it exposes the name of the customer but stored on casper in /home/support/689581/-- And the command line to reproduce the crash (hopefully): gs -sDEVICE=tiffsep -sOutputFile=a.tif -r72 -dNOPSICC -dNOPAUSE -f Poster_DEC.pdf -c quit From what I understand of the problem, all files having transparency are potentially affected, as soon as tiffsep is in use (tiffsep is the only standard device using the pdf14_CMYKSpot device). However, the problem seems to happen more often when the file has a big number of Spot colors (the one above has 12) and, maybe, when the Spots have complex interactions (e.g. overprints). I'm not sure of that. Finally, to answer Leonardo's comment in the bugtracker: that has definitevely nothing to do with shading, and probably nothing to do with the "separable_and_linear" property either (I've had crashes on some files that didn't even have any gradation). However I agree with him that the pdf14_CMYKSpot device should not be separable.
Created attachment 4494 [details] diff.txt Customers patch which replaces gs_alloc_struct() with malloc().
Raising priority for a crash and making the bug bountiable per Alex's suggestion.
It no longer core dumps with head (r9784), but valgrind reports the same problem so it's not fixed.
I can reproduce the valgrind warnings from #2 on linux x86_64. There are also earlier warnings about uninitialized memory in the garbage collector.
Tried with 8.70rc1 (r9907). Panneau1.pdf (bin/gs -sDEVICE=tiffsep -sOutputFile=a.tif -r30 ./Panneau1.pdf) worked fine. Poster_DEC.pdf (gs -sDEVICE=tiffsep -sOutputFile=a.tif -r72 -dNOPSICC -dNOPAUSE -f Poster_DEC.pdf -c quit) didn't crash but the job aborted with /rangecheck in -- showpage--. $ bin/gs -sDEVICE=tiffsep -sOutputFile=a.tif -r72 -dNOPSICC -dNOPAUSE -f Poster_DEC.pdf -c quit GPL Ghostscript 8.70 (2009-07-28) Copyright (C) 2009 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 %%SeparationName: 60 %%SeparationName: PANTONE 3285 C %%SeparationName: PANTONE 139 C %%SeparationName: PANTONE 658 C %%SeparationName: PANTONE 425 C %%SeparationName: 20 %%SeparationName: PANTONE 367 C %%SeparationName: 56 %%SeparationName: 48 %%SeparationName: 42 %%SeparationName: 40 %%SeparationName: PANTONE 138 C Error: /rangecheck in --showpage-- Operand stack: 1 true Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push - -nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1862 1 3 %oparray_pop 1861 1 3 %oparray_pop 1845 1 3 %oparray_pop --nostringval-- -- nostringval-- 2 1 1 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- 1745 0 9 %oparray_pop --nostringval-- --nostringval-- Dictionary stack: --dict:1149/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:75/200(L)-- -- dict:106/127(ro)(G)-- --dict:285/300(ro)(G)-- --dict:22/25(L)-- --dict:4/6(L)-- -- dict:22/40(L)-- Current allocation mode is local Last OS error: 2 GPL Ghostscript 8.70: Unrecoverable error, exit code 1 Same result in both Mac OS X 10.5.7 + Xcode 3.1.2 and Win XP Pro SP3 + VS2008SP1.
Created attachment 5257 [details] valgrind.log Valgrind is still showing the error; I suspect a recent change moved things around in memory so the crash no longer occurs, but the problem is likely not fixed. I've attached a complete valgrind log from peeves.
I would retry this after I do a commit to fix 690670.
Passing to Michael.
I have found the problem with this. Somehow we are getting spot colors coming into the construction of a soft mask. This should never occur even when the device is a sep device. All spot colors for a soft mask need to go through the tint transform so that all incoming color spaces to the soft mask are either gray, RGB, or CMYK. These we then convert to luminance to create the mask. Next step is to figure out why we are not doing the tint transform.
Actually let me take back my previous comment. The softmask is getting filled with a pattern. When the number of components is checked for the color space it returns -1. This causes an error due to my switch statement which is looking for gray, rgb or cmyk number of componenents. This pattern does not have a base space, so it returns -1. I need to spend a little time figuring out what is in this pattern and how to convert it to luminance for the soft mask.
Created attachment 5361 [details] Bug689581_Simple.pdf This file is a simplified file that shows the rendering issue that remains after commit 10059 which fixed the range error problem. The rendering problem occurs only with separation devices (e.g. tiffsep). The issue is that the data for the softmask is encoded using devn_encode_compressed_color and then decoded using pdf14_unpack_subtractive. I should have a fix for this issue soon.
This should be fixed with rev. 10062
Changing customer bugs that have been resolved more than a year ago to closed.