I'm not able to duplicate this on my amd64 linux nor my g5 linux boxes with 8.62
nor head (r8825).  It may be a Windows issue.

Note that the -Z$?@ options ONLY are relevant for DEBUG=1 builds and common
shell escapes are needed, thus this needs to be written on a sh/bash/ksh
command line as -Z\$\?@

I suspect that Marcos did not have a DEBUG build.

Right, I didn't use a debug build.  I am able to duplicate the issue with head
but not with 8.62, so I'm checking to see what rev. is responsible.

search-svn-revs says that r8585 is the first revision that has this problem. 
Reading the (rather lengthy) log entry it appears that this may indeed by correct.

This regression, with 'reference to free object' can cause crashes on some
systems, depending on GC execution which may free the chunk containing the
free object.

Assigning to Igor who authored rev 8585.

The reference to a free object appears in an st_pdf14_buf type object at ptr 
index 0. It is pdf14_buf::saved. IMO the patch 8585 is unrelated, but it is 
still my autorship.

BTW the log 8585 message isn't long in spite of Comment #4 reads. Is Comment 
#4 correct at all ?

BTW st_pdf14_buf is defined 2 times : once in gdevp14.c and another time in 
gdevpnga.c . The latter is not build with MSVC makefile, so it has to be 
deleted or at least to be rewritten.

Created attachment 4221 [details]
patch.txt

A suggested patch is being tested locally.

I've double checked and comment #4 is correct regarding the revision.  I agree
the log message isn't that long, but is longer than most:

------------------------------------------------------------------------
r8585 | leonardo | 2008-03-03 08:01:12 -0800 (Mon, 03 Mar 2008) | 79 lines

Fix (clist) : Crop transparencsy commands while clist writing, step 3.

DETAILS :

This really crops transparency compositor commands with bands 
that are covered by the transparency bbox.

Actually the statement above has one exception. When a transparency bbox
covers more that 2/3 of all bands, we still write the commands to 
the "all bands" list for a shorter clist file. We noticed that 
the clist playback time strongly depends on the file size.

1. The new method gs_composite_type_procs_t::get_cropping
replies what bands are covered by the compositor. 
When it gives a non-trivial result, clist_create_compositor
writes the compositor command to those bands,
which are covered with the cropping (Exception :
if too many bands are covered, it writes the command to
the "for all bands" list).

2. Since some bands skip some compositor commands,
while clist reading the association of masks to groups 
becomes more complex. Before this patch each group
was associates with the mask, which was created immediately
before it at same transparency stack level. 
After this patch some groups may be skipped, so that
clist reader may recieve extra masks, because masks are
still use the container's group bbox. For skipping such extra masks
we provide a numeric identifier of a mask, which is named mask_id.
Here is how it works :

2.1. All masks recieve serial numbers (mask_id) while clist writing.
2.2. Each mask command is written with its mask_id.
2.3. Each group command is writen with mask_id, 
     which belongs to the mask that is assocuated with the group.
2.4. While clist playback pdf14_pop_transparency_group checks whether
     the mask amd the group have same mask_id. If not, the mask is extra
     and it must be droped.
2.5. Note the old assiciation logic is still working,
     and it may skip some masks as well.
2.6. If the rasterization happens with no clist, mask_id is always zero.
     In this case the old logics is only working.
     Maybe we'll provide non-zero values someday.
2.7. See comments in code for more details.

3. The method gs_composite_type_procs_t::clist_compositor_write_update
is now some generalized. Before this patch it only updates the clist writer state
with the compositor features. With this patch it also adds 
some information from the clist writer state to the compositor parameters.
Particularly it provides mask_id to the compositor command.
Thus now it updates *both* clist writer and the compositor parameters
to comply each another. For a while, in order to simplify the patch,
the compositor argument is still 'const'. Will need to fix someday.

4. Now we need to save mask_id in a stack that reflects the
transparency nesting. The cropping stack, which was introduced
in the last patch, now works for that. To provide that
we add mask_id to clist_writer_cropping_buffer_s,
and use clist_writer_push_no_cropping to save amsk_id
over inner groups. 

5. state_update(ctm) in c_pdf14trans_clist_write_update is replaced
with code, which updates CTM from the transparency compositor command.
The old code is not fully correct, because it takes CTM from the imager state,
rather we havn't got prcatical cases when it gives a wrong result.

6. drop_compositor_queue now calls adjust_ctm for compositors being dropped.
The old code is incorrect because it can miss a CTM update when 
a compositor sets some CTM and later a non-compositor object
sets same CTM. In this case the clist writer skips the second CTM on writing,
and skipping the first in the clist reader will miss the CTM completely.
We haven't got practical cases for that.

7. Improved some debug printing.

EXPECTED DIFFERENCES :

None.      

------------------------------------------------------------------------

r8585 was originally committed with an incorrect (quite short) log message, I
suspect this is the source of the confusion.

Thanks to Ken and Marcos, I noticed same inconsistency as ken notices in 
Comment #10. My mistake happened due to I initialluy read 
http://ghostscript.com/pipermail/gs-cvs/2008-March/008170.html .

The patch passed the local testing. Passing the bug to Henry because the 
ownersip is unclear, and because our testing environment is imperfect.

Please commit the patch. Thanks.

Patch to HEAD "
http://ghostscript.com/pipermail/gs-cvs/2008-July/008426.html