I have a pdf which seems to cause gs head (8.63) to segfault if run with the "-sDEVICE=pdfwrite -c .setpdfwrite -f <file>" syntax instead of just "-sDEVICE=pdfwrite <file>" syntax. (i.e. ps2pdf [which uses the former] segfaults, but -sDEVICE=pdfwrite <file> with exactly the same options works). I have a suspicion that it is because one of the embedded eps's have this: ============= /pdfmark where { pop globaldict /?pdfmark /exec load put } % pdfmark is built-in { globaldict begin /?pdfmark /pop load def % pdfmark is absent /pdfmark /cleartomark load def end } ifelse ============ but I am not sure why the eps itself distills okay, but when it is embedded it causes gs to segfault.
Created attachment 4473 [details] the problematic ps file, gz'ed The problematic ps file, gz'ed.
I can reproduce this on my Linux 64 box but on my MacBook Pro. I'm not sure if it's a linux/mac os x or 64 bit/32 bit difference. Continuing to investigate.
It looks like a 64 bit only problem. On my G5 running Linux the -m64 build segfaults but the -m32 build does not.
Yes, I am on 64-bit linux. Was a bit undecided about "PC" or "Other" in the "Platform". Could we have AMD64 or some such under "Platform"?
Unfortunately, we cannot have a 64 bit platform option. See Bug 690092.
This may be a red herring, but r8854 is the first revision which fails under 64 bit: r8854 | alexcher | 2008-07-21 11:55:31 -0700 (Mon, 21 Jul 2008) | 8 lines Wrap string data source into a procedure when /ImscaleDecode filter is installed, to ensure repeated reading of the string when the imagemask needs more data than has the string. Allocate new composite objects with the same global status as old ones. Bug 689889, customer 330.
Hmm, I don't currently have access to a 64-bit OS, this could delay things....
Assign to me for further analysis on Marcos' 64-bit machine
Created attachment 4486 [details] with_setpdfwrite.txt valgrind output from the command line: bin/gs -o test.pdf -sDEVICE=pdfwrite -c .setpdfwrite -f WTCCC_workflow_and_beyond.ps
Created attachment 4487 [details] without_setpdfwrite.txt bin/gs -o test.pdf -sDEVICE=pdfwrite -f WTCCC_workflow_and_beyond.ps
Created attachment 4488 [details] with_setpdfwrite_32bit.txt For comparison I compiled Ghostscript with -m32. Here is the valgrind output from the command line: bin/gs -o test.pdf -sDEVICE=pdfwrite -c .setpdfwrite -f WTCCC_workflow_and_beyond.ps
Created attachment 4489 [details] without_setpdfwrite_32bit.txt And the same -m32 without the setpdfwrite: bin/gs -o test.pdf -sDEVICE=pdfwrite -f WTCCC_workflow_and_beyond.ps
The patch for the bug 690129 also fixes this one. *** This bug has been marked as a duplicate of 690129 ***