Created attachment 6369 [details] Postscript file that triggers Invalid write If I run gs -sDEVICE=laserjet on the attached file (fe1af3.ps) with valgrind, valgrind reports an Invalid read and Invalid write error in names_trace_finish (iname.c:424). The code appears to be accessing memory after it was freed. Invalid write errors and use-after-free errors sometimes indicate a security vulnerability. To reproduce: valgrind --track-origins=yes --read-var-info=yes --suppressions=afgs-source/gs/toolbin/vg_bugs.supp --suppressions=afgs-source/gs/toolbin/vg_okay.supp afgs-source/gs/bin/gs.debug -q -dNOPAUSE -dBATCH -sDEVICE=laserjet -sOutputFile=/dev/null fe1af3.ps > vg_fe1af3.out 2>&1 I've attached the problematic Postscript file (fe1af3.ps) as well as Valgrind's output (vg_fe1af3.out). This test case also finds some possibly-new Valgrind warnings associated with use of uninitialized values. I don't know whether they matter. I've also attached a somewhat smaller file (smaller.ps) that triggers the same Invalid write error, and a file with Valgrind's output on this smaller file (vg_smaller.out). The smaller file was generated using an automatic testcase minimization tool I wrote for Postscript files. This is confirmed in Subversion revision 11345.
Created attachment 6370 [details] Valgrind output for fe1af3.ps
Created attachment 6371 [details] Somewhat smaller file that appears to trigger the same Invalid write
Created attachment 6372 [details] Valgrind output for smaller.ps
This looks to be the same issue as 691005, but may be easier to debug this one.
I've reproduced this problem on amd64 GNU/Linux box with the following command line: valgrind gs/debugobj/gs -o /dev/null -dNOGC -sDEVICE=nullpage smaller.ps So far I was unable to reproduce this bug on i686 GNU/Linux system. *** This bug has been marked as a duplicate of bug 691005 ***