When processing a Japanese document containing 3 TeX "CM" fonts and two Japanese fonts (the Japanese fonts can be msmincho.ttc and msgothic.ttc, or kochi-mincho.ttf and kochi-gothic.ttf; the crash is identical, right down to the count and element of the glyph cache when the crash occurs). It appears but I cannot verify that the crash occurs when trying to process the second Japanese font, which happens to be the gothic font, for the first time. If the cache is disabled by arranging that gs_glyph_cache_elem__locate() always returns NULL, the document prints normally as far as I can tell. I built variously with GCC 3.2 and 3.3, with optimization -O0 and -O2. All crash in the same way, but with somewhat different cache contents at the time of the crash. The content of the document is sensitive; I can't provide it but will try to produce a test case upon request. The Kochi fonts are commonly available, eg, from Linux distributions. gdb output attached, for what it's worth. I think this one may be accurate, but recently gdb (Debian GNU/Linux sid distribution definitely bleeds at times, and this is one) has been producing really bizarre backtraces (claiming that the global argv is located at 0x31 and things like that), so be aware that gdb-reported addresses are suspect. This GDB was configured as "i386-linux"... (gdb) set gs_debug_glyph_cache_enable = 1 Cannot access memory at address 0x82fb500 (gdb) break main Breakpoint 1 at 0x804b8e0: file src/gs.c, line 43. (gdb) run -sFONTPATH=/var/lib/defoma/gs.d/dirs -sGenericResourceDir=/home/stephe n/Projects/Ghostscript/gs/Resource/ /coda/tleepslib.sk.tsukuba.ac.jp/Teaching/MB A/Nyuushi/tmp.ps Starting program: /home/stephen/Projects/Ghostscript/gs/bin/gs -sFONTPATH=/var/l ib/defoma/gs.d/dirs -sGenericResourceDir=/home/stephen/Projects/Ghostscript/gs/R esource/ /coda/tleepslib.sk.tsukuba.ac.jp/Teaching/MBA/Nyuushi/tmp.ps Breakpoint 1, main (argc=4, argv=0xbffffa04) at src/gs.c:43 43 int exit_status = 0; (gdb) set gs_debug_glyph_cache_enable = 1 (gdb) disable 1 (gdb) c Continuing. AFPL Ghostscript CVS PRE-RELEASE 8.12 (2003-08-18) Copyright (C) 2003 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Scanning /var/lib/defoma/gs.d/dirs for fonts... 2 files, 2 scanned, 0 new fonts. Loading a TT font from /usr/share/fonts/truetype/kochi/kochi-mincho.ttf to emula te a CID font Ryumin-Light ... Done. Loading a TT font from /usr/share/fonts/truetype/kochi/kochi-gothic.ttf to emula te a CID font GothicBBB-Medium ... Done. >>showpage, press <return> to continue<< >>showpage, press <return> to continue<< >>showpage, press <return> to continue<< Program received signal SIGSEGV, Segmentation fault. 0x081f8d31 in gs_glyph_cache_elem__locate (this=0x8433fdc, glyph_index=2703) at src/gsgcache.c:122 122 if ((*e)->glyph_index == glyph_index) (gdb) print *this->list $1 = {gd = {bits = {data = 0xbfff0e00 "", size = 134727728, bytes = 0x100 <Address 0x100 out of bounds>}, procs = 0x0, proc_data = 0xe00}, glyph_index = 0, lock_count = 3221160568, next = 0x84088b0} (gdb) print *$1.next $2 = {gd = {bits = {data = 0x41046a <Address 0x41046a out of bounds>, size = 138447084, bytes = 0x410478 <Address 0x410478 out of bounds>}, procs = 0x83fea90, proc_data = 0xb00}, glyph_index = 46, lock_count = 2816, next = 0x30} (gdb) print *$2.next Cannot access memory at address 0x30 (gdb) print (*e) $3 = (gs_glyph_cache_elem *) 0x30 (gdb) bt #0 0x081f8d31 in gs_glyph_cache_elem__locate (this=0x8433fdc, glyph_index=2703) at src/gsgcache.c:122 #1 0x081f8dc3 in gs_get_glyph_data_cached (pfont=0x8433db8, glyph_index=2703, pgd=0xbfffe790) at src/gsgcache.c:162 #2 0x0806ddd7 in gs_type42_default_get_metrics (pfont=0x8433db8, glyph_index=2703, wmode=0, sbw=0xbfffe800) at src/gstype42.c:635 #3 0x0806defb in gs_type42_wmode_metrics (pfont=0x8433db8, glyph_index=2703, wmode=0, sbw=0xbfffe800) at src/gstype42.c:667 #4 0x0806b704 in zchar42_set_cache (i_ctx_p=0x831f158, pbfont=0x8433db8, cnref=0x8313894, glyph_index=2703, cont=0x806bab9 <type42_fill>, exec_cont=0xbfffe89c, put_lsb=1) at src/zchar42.c:56 #5 0x0806ba8b in ztype42execchar (i_ctx_p=0x831f158) at src/zchar42.c:144 #6 0x080b1025 in interp (pi_ctx_p=0x82fbe24, pref=0xbfffef18, perror_object=0xbfffefd8) at src/interp.c:1492 #7 0x080aed77 in gs_call_interp (pi_ctx_p=0x82fbe24, pref=0xbfffef18, user_errors=1, pexit_code=0xbfffefe4, perror_object=0xbfffefd8) at src/interp.c:487 #8 0x080aec43 in gs_interpret (pi_ctx_p=0x82fbe24, pref=0xbfffef18, user_errors=1, pexit_code=0xbfffefe4, perror_object=0xbfffefd8) at src/interp.c:445 #9 0x080a6061 in gs_main_interpret (minst=0x82fbc20, pref=0xbfffef50, user_errors=1, pexit_code=0xbfffefe4, perror_object=0xbfffefd8) at src/imain.c:297 #10 0x080a6987 in gs_main_run_string_end (minst=0x82fbc20, user_errors=1, pexit_code=0xbfffefe4, perror_object=0xbfffefd8) at src/imain.c:600 #11 0x080a6882 in gs_main_run_string_with_length (minst=0x82fbc20, str=0x8324010 "<2f636f64612f746c656570736c69622e736b2e7473756b7562612e61632e 6a702f5465616368696e672f4d42412f4e7975757368692f746d702e7073>.runfile", length=130, user_errors=1, pexit_code=0xbfffefe4, perror_object=0xbfffefd8) at src/imain.c:558 #12 0x080a6813 in gs_main_run_string (minst=0x82fbc20, str=0x8324010 "<2f636f64612f746c656570736c69622e736b2e7473756b7562612e61632e 6a702f5465616368696e672f4d42412f4e7975757368692f746d702e7073>.runfile", user_errors=1, pexit_code=0xbfffefe4, perror_object=0xbfffefd8) at src/imain.c:540 #13 0x080a8d1f in run_string (minst=0x82fbc20, str=0x8324010 "<2f636f64612f746c656570736c69622e736b2e7473756b7562612e61632e 6a702f5465616368696e672f4d42412f4e7975757368692f746d702e7073>.runfile", options=3) at src/imainarg.c:772 #14 0x080a8cd9 in runarg (minst=0x82fbc20, pre=0x82640bb "", arg=0x8324220 "/coda/tleepslib.sk.tsukuba.ac.jp/Teaching/MBA/Nyuushi/tmp.ps" , post=0x826415d ".runfile", options=3) at src/imainarg.c:763 #15 0x080a8a27 in argproc (minst=0x82fbc20, arg=0xbffffb82 "/coda/tleepslib.sk.tsukuba.ac.jp/Teaching/MBA/Nyuushi/tmp.ps ") at src/imainarg.c:698 #16 0x080a7969 in gs_main_init_with_args (minst=0x82fbc20, argc=4, argv=0xbffffa04) at src/imainarg.c:216 #17 0x0804b900 in main (argc=4, argv=0xbffffa04) at src/gs.c:45 (gdb)
Thank you for testing Ghostscript. You don't need to make the file public. Ghostscript Bugzilla supports private attachments visible only to a small group of active GS developers. If private attachment is still unacceptable, try to create a special sample file. There are 2 ways to do it: You can try to create another document with some random text but the same formatting, fonts, etc. Sometimes it is easier to remove most of the original document until it is no longer sensitive, but still demonstrates the problem.
Or alternatively, send the file via email to me at jack@artifex.com, and I will put it on our private server for the other Artifex employees to investigate.
We'll need a test file for this in order to make any progress. Please reopen once you've attached one (you can mark it private once it is attached).
Created attachment 767 [details] file containg Japanese text; causes all recent versions of GS to segfault Uses truetype fonts. Seems to matter which ones (always get a crash, but the output file differs, some get farther than others). cidfmap file attached separately.
Created attachment 768 [details] cidfmap describing location of tt fonts used the kochi/naga10 fonts mentioned in that file also crash GS haven't tested that recently because Debian broke the font files a while back and I'm not sure what went wrong.
Sorry about the long delay. I detest web interfaces (which is not your problem) and since I was expecting email from the bug system and never saw any (maybe my spam filter is too agressive?), I asumed y'all were ignoring me. Sorry about that. I commented with the PS file attachment that the ms and kochi fonts behave differently, but that's probably bogus. I do know that the crash happens in different places with different GS versions, but that's not surprising if it's stack smashing or tromping on the malloc arena. Since I wrote in the oriingal report that they're the same "down to the count and element", I'll stick to that.
jack, can you please verify that this is still an issue? I don't have the fonts in question.
I think the problem is already fixed somehow? I have all the 4 Japanese fonts mentioned, and just tried Stephen's ps test file (comment 4), and editing Stephen's cidmap (comment 5) to load each of the font files in turn, and they all work alright with ghostscript 8.51 - Stephen's test ps file only tries to load exactly one japanese font (Ryumin-Light) though, unlike the initial report; but I am able to load both of the MS fonts with gs 8.51 elsewhere (see bug 687825). oh, I can read a bit of Japanese. (Just being helpful, as I have the fonts handy. Hi Stephen - we had some lengthy MULE/cxterm discussion once a few years ago...)
Since this is an old bug, and we don't have any reports that recent GS has a problem, closing as WORKSFORME