[gs-bugs] [Bug 689731] ps2pdf segfault

bugs.ghostscript.com-bugzilla-daemon at ghostscript.com bugs.ghostscript.com-bugzilla-daemon at ghostscript.com
Tue Apr 1 10:49:55 PDT 2008


------- Additional Comments From keinbiervorvier at gmail.com  2008-04-01 10:49 -------


clearly the Fontmap.GS does not have a logical connection to the pdf color
namespaces, but this being a segfault, it can have indirect influence on memory
allocation, etc.

When I checked, the Fontmap.GS was the only local customization and it triggered
the segfault. Note also, that for some svn revisions the -dNOFONTMAP switch
avoids the segfault.

I have been using current HEAD and regularly re-checking for the past month.

$ svn up
At revision 8617.
$ make distclean ; make && make install
$ ps2pdf gscoredump.eps
Segmentation fault (core dumped)


Core was generated by `gs -dSAFER -dCompatibilityLevel=1.4 -q -dNOPAUSE -dBATCH
-sDEVICE=pdfwrite -sOu'.
Program terminated with signal 11, Segmentation fault.
#0  0x080e89be in names_string_ref ()
(gdb) bt
#0  0x080e89be in names_string_ref ()
#1  0x080ff46d in gs_get_colorname_string ()
#2  0x0821403d in pdf_color_space_named ()

However this generates PDF (on Fedora Core8 i386)
$ps2pdf -dNOFONTMAP gscoredump.eps

but still fails on Fedora Core8 x86_64.

When I run gs through gdb with a breakpoint at iname.c:names_string_ref
the call to const name_string_t *pnstr = names_string_inline(nt, pnref);
returns a nullpointer for *pnstr after 20232 hits and the subsequent access in
make_const_string segfaults.

I don't understand the pdf color namespace handling to debug much further.

I attach a figure (same as in original attachment, but standalone instead of
inlined in text).

Interestingly I can split the figure in 2 parts and distill these individually,
as long as the number of (New Color ..) operations is below 728.

Hope this helps

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

More information about the gs-bugs mailing list