Created attachment 10945 [details]
alloc-trace.txt.xz

I have a repeatable segfault. Unfortunately, I am not able to share the input file. :-(

https://bugzilla.redhat.com/show_bug.cgi?id=1086428

I am seeing this with ghostscript-9.10-5.fc20.x86_64 on Fedora 20. Here is the command line:

gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.3 -dAutoRotatePages=/None -dAutoFilterColorImages=false -dNOPLATFONTS -dPARANOIDSAFER -dNOINTERPOLATE -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/printer -dUseCIEColor -dColorConversionStrategy=/LeaveColorUnchanged -dDoNumCopies -r600 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -sOutputFile=/dev/null -c .setpdfwrite my_v2.ps

Running under valgrind shows this:

==14433== Invalid write of size 8
==14433==    at 0x4A0A555: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==14433==    by 0x4EBB9B8: s_Bicubic_process (string3.h:51)
==14433==    by 0x4DC2115: s_process_write_buf (stream.c:902)
==14433==    by 0x4DC23A6: spputc (stream.c:488)

and under gdb with a -DDEBUG build:

Program received signal SIGSEGV, Segmentation fault.
0x000000000081f5ad in i_free_object (mem=0x16a54f8, ptr=0x1fae108, 
    cname=0x9c4d20 "Bicubic data") at ./base/gsalloc.c:874
874	    finalize = pstype->finalize;
Missing separate debuginfos, use: debuginfo-install avahi-libs-0.6.31-21.fc20.x86_64 expat-2.1.0-7.fc20.x86_64 fontconfig-2.11.0-1.fc20.x86_64 freetype-2.5.0-5.fc20.x86_64 keyutils-libs-1.5.9-1.fc20.x86_64 krb5-libs-1.11.5-5.fc20.x86_64 lcms2-2.6-1.fc20.x86_64 libICE-1.0.8-6.fc20.x86_64 libSM-1.2.1-6.fc20.x86_64 libXau-1.0.8-2.fc20.x86_64 libXt-1.1.4-7.fc20.x86_64 libcom_err-1.42.8-3.fc20.x86_64 libselinux-2.2.1-6.fc20.x86_64 libxcb-1.9.1-3.fc20.x86_64 nss-softokn-freebl-3.16.1-1.fc20.x86_64 openssl-libs-1.0.1e-37.fc20.1.x86_64 pcre-8.33-4.fc20.x86_64 xz-libs-5.1.2-8alpha.fc20.x86_64
(gdb) up
#1  0x00000000006b0061 in s_Bicubic_release (st=0x1b58770)
    at ./devices/vector/gdevpsds.c:863
863	    gs_free_object(st->memory, ss->data, "Bicubic data");
(gdb) p ss->data
$1 = (byte *) 0x1fae108 '\377' <repeats 200 times>...

From that same gdb run (with -ZA) I captured the allocation debug messages (attached).

The relevant pieces seem to be:

Line 447170, 0x1fae0d0 is allocated (184 bytes, I think for a name sub-table?)
Line 905068, 0x1fae108 is allocated (59364 bytes, for Bicubuc data)
Line 905556, 0x1fae0d0 is freed.

When 0x1fae108 is allocated, it seems to overlap with already-allocated memory.

Trace attached.