Created attachment 11596 [details] Test file that exhibits the bug. Needs the font YuMincho-Regular Dear all, Norbert Preining from the TeX Live project. With some colleagues from Japan we are trying to setup CJK fonts for GhostScript, and in this course we stumbled on a bug that was introduced after 9.08. gs consistently segfaults when interpreting a PostScript file with references to YuMin-Medium, a Japanese font distributed with MacOSX: $ otfinfo --info "Yu Mincho Medium.otf" Family: YuMincho Subfamily: Medium Full name: YuMincho Medium PostScript name: YuMin-Medium Preferred family: YuMincho Preferred subfamily: Medium Version: 8.1d1e1 Unique ID: YuMincho Medium; 8.1d1e1; 2014-05-02 Designer: JIYUKOBO Ltd. Designer URL: http://www.jiyu-kobo.co.jp/ Manufacturer: JIYUKOBO Ltd. Vendor URL: http://www.jiyu-kobo.co.jp/ Trademark: Yu Type Library is a Trademark of JIYUKOBO Ltd. Copyright: Copyright © 2012 JIYUKOBO Ltd. All Rights Reserved. License URL: http://www.jiyu-kobo.co.jp/ This problem happened with gs 9.16 on OSX, while my gs 9.06 on Linux worked. So I started bisecting the code and can confirm that the following commit introduced the segmentation fault: commit 579e9024d1bc358fe12bcceb00e1ba1797e473ec Author: Chris Liddell <chris.liddell@artifex.com> Date: Mon Jun 17 08:52:37 2013 +0100 Bug 694319 (related): bounds checking T1 op stack Add some lower bounds checking for the operand stack, to one of the Type 1 charstring interpreters used by pdf/ps2write. This fixes one of the memory corruption problems with Bug693711.pdf. No cluster differences. I also confirmed that the crash still occurs in git HEAD, and that reverting this patch makes the segfault go away. The font is installed as follows: * copy (or link) the font into Resource/CIDFont/YuMincho-Regular (without the .otf extension) * create a snippet in Resource/Font/YuMincho-Regular-H that defines the font: %%!PS-Adobe-3.0 Resource-Font %%%%DocumentNeededResources: H (CMap) %%%%IncludeResource: H (CMap) %%%%BeginResource: Font (YuMincho-Regular-H) (YuMincho-Regular-H) (H) /CMap findresource [(YuMincho-Regular) /CIDFont findresource] composefont pop %%%%EndResource %%%%EOF I attach the PostScript file for your convenience. The file was generated with platex (Japanese TeX) plus dvips. In the same way we have set up many other Japanese fonts without problems, so we believe that this is not a setup problem from our side. Thanks for consideration, and if you want me to test any proposed patches, please let me know. Sincerely yours Norbert
I confess to being puzzled as to how a change in the Type 1 charstring code can affect the interpreting of an OTF font, since OTF can only contain TTF and CFF outlines (*not* Type 1 outlines). My OS X install I don't have that font so I assume it's either from a newer version than I have, or is part of the Japanese language install, furthermore, even if I can find a copy, it's not certain to be the same version with which you see the problem. For me to investigate, I'll really need you to make the font available to me (you can attach it here, put it somewhere for me to download, or e-mail it to me at the address associated with my bugzilla username). I realise there may be copyright issues to consider, and if that is the case, I undertake to delete the font file once I have completed investigation of the issue. Lastly, you haven't supplied a command line - I'll need a complete and accurate Ghostscript command line to reproduce the problem.
Hi Chris, thanks for your answer. Today I'm tight (and it is already late afternoon here in Japan), but tomorrow I send you more details including gdb backtraced here in bugzilla, and the font via email. Thanks Norbert
(In reply to Norbert Preining from comment #2) > Hi Chris, > thanks for your answer. Today I'm tight (and it is already late afternoon > here in Japan), but tomorrow I send you more details including gdb > backtraced here in bugzilla, and the font via email. TBH, just the font and the command line are needed. If I can reproduce the problem, I can see the backtrace for myself. If I can't reproduce it, the backtrace is almost certainly not going to help.
I have that exact same font on my Yosemite install. Maverick's reports: Version: Version 1.000;PS 1;hotconv 1.0.57;makeotf.lib2.0.21895 Unique ID: 1.000;JY ;YuMin-Medium while Yosemite's reports: Version: 8.1d1e1 Unique ID: YuMincho Medium; 8.1d1e1; 2014-05-02 md5 sums: d57bfd16d4c8426c956d9d2e5eb157a5 Maverick's 3a55c3d449d200d12d55459d84d3310c Yosemite's Yosemite's is about 2k larger in size. 10645572 10647312 I don't think I did anything special while installing the English version of the OS, but then I would normally select any optional CJK support if such is offered...
Hi Chris, I sent you a minimal example with all necessary files per email. If you need anything else, please let me know. Norbert
(In reply to Norbert Preining from comment #5) > Hi Chris, > > I sent you a minimal example with all necessary files per email. > > If you need anything else, please let me know. > > Norbert Thanks, that was perfect. Fixed in: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=e2f65f3e