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.