Starting with r11071 I get a seg fault with the following command line: ./bin/gs -sOutputFile='Bug687546.ps.pdf.pkmraw.300.0.pdf' -I/Users/marcos/artifex/peeves/regression/gshead/lib/:/Users/marcos/artifex/peeves/regression/fonts/ -sDEVICE=pdfwrite -q -Z: -dNOPAUSE -dBATCH -K1000000 -dMaxBitmap=30000000 -dNOOUTERSAVE -dJOBSERER -c false 0 startjob pop -f - < /home/marcos/artifex/tests_private/comparefiles/Bug687546.ps Unfortunately it seems to be heavily dependent on which system I run it on, what the directory is called, and what the command line is (hence the odd -I options). Also, it doesn't seg fault with the debug build. The good news is that valgrind reports something . . . ==25384== Conditional jump or move depends on uninitialised value(s) ==25384== at 0x5D53A5: FAPI_refine_font (zfapi.c:1232) ==25384== by 0x5D5D1D: zFAPIrebuildfont (zfapi.c:1349) ==25384== by 0x4C7E9F: call_operator (interp.c:118) ==25384== by 0x4CA7EA: interp (interp.c:1174) ==25384== by 0x4C8552: gs_call_interp (interp.c:508) ==25384== by 0x4C838C: gs_interpret (interp.c:466) ==25384== by 0x4BBC0B: gs_main_interpret (imain.c:214) ==25384== by 0x4BC7C8: gs_main_run_string_end (imain.c:526) ==25384== by 0x4BC685: gs_main_run_string_with_length (imain.c:484) ==25384== by 0x4BC5F2: gs_main_run_string (imain.c:466) ==25384== by 0x4BF732: run_string (imainarg.c:815) ==25384== by 0x4BDE51: swproc (imainarg.c:282) ==25384== ==25384== Conditional jump or move depends on uninitialised value(s) ==25384== at 0x522FB7: alloc_save_change_in (isave.c:494) ==25384== by 0x5230C2: alloc_save_change (isave.c:517) ==25384== by 0x5D53D0: FAPI_refine_font (zfapi.c:1232) ==25384== by 0x5D5D1D: zFAPIrebuildfont (zfapi.c:1349) ==25384== by 0x4C7E9F: call_operator (interp.c:118) ==25384== by 0x4CA7EA: interp (interp.c:1174) ==25384== by 0x4C8552: gs_call_interp (interp.c:508) ==25384== by 0x4C838C: gs_interpret (interp.c:466) ==25384== by 0x4BBC0B: gs_main_interpret (imain.c:214) ==25384== by 0x4BC7C8: gs_main_run_string_end (imain.c:526) ==25384== by 0x4BC685: gs_main_run_string_with_length (imain.c:484) ==25384== by 0x4BC5F2: gs_main_run_string (imain.c:466) ==25384== ==25384== Conditional jump or move depends on uninitialised value(s) ==25384== at 0x520301: ialloc_validate_ref_packed (ilocate.c:372) ==25384== by 0x520193: ialloc_validate_chunk (ilocate.c:344) ==25384== by 0x51FDBD: ialloc_validate_memory (ilocate.c:248) ==25384== by 0x5197EF: gc_validate_spaces (igc.c:145) ==25384== by 0x519A91: gs_gc_reclaim (igc.c:246) ==25384== by 0x5C1BF9: context_reclaim (zcontext.c:283) ==25384== by 0x4CFB76: gs_vmreclaim (ireclaim.c:153) ==25384== by 0x4CF8DA: ireclaim (ireclaim.c:75) ==25384== by 0x4C82F6: interp_reclaim (interp.c:439) ==25384== by 0x4CC583: interp (interp.c:1702) ==25384== by 0x4C8552: gs_call_interp (interp.c:508) ==25384== by 0x4C838C: gs_interpret (interp.c:466) ==25384== ==25384== Conditional jump or move depends on uninitialised value(s) ==25384== at 0x522315: change_clear_marks (isave.c:180) ==25384== by 0x51ABCE: gc_objects_clear_marks (igc.c:601) ==25384== by 0x519AE2: gs_gc_reclaim (igc.c:260) ==25384== by 0x5C1BF9: context_reclaim (zcontext.c:283) ==25384== by 0x4CFB76: gs_vmreclaim (ireclaim.c:153) ==25384== by 0x4CF8DA: ireclaim (ireclaim.c:75) ==25384== by 0x4C82F6: interp_reclaim (interp.c:439) ==25384== by 0x4CC583: interp (interp.c:1702) ==25384== by 0x4C8552: gs_call_interp (interp.c:508) ==25384== by 0x4C838C: gs_interpret (interp.c:466) ==25384== by 0x4BBC0B: gs_main_interpret (imain.c:214) ==25384== by 0x4BC7C8: gs_main_run_string_end (imain.c:526) ==25384== . . .
Hmm this seems to be something to do with garbage collection and save/restore. I wonder if we are creating a new array in local/global memory which is different to the memory allocation of the original font ? I can't see anything obviously wrong with the code in FAPI_refine_font in zfapi.c otherwise.
I've tried to reproduce the problem, with as similar a command line as I can on my machine (different paths, but both the same length) and I cann't get a seg fault, nor a matching valgrind error. Valgrind does show some issues in the garbage collection, but in different places to Marcos's, and in mine there is no mention of the FAPI code from Valgrind at all. Query: does /Users/marcos/artifex/peeves/regression/fonts/ contain a different font set to the normal GS fonts - it would be another difference in configurations?
I may have reproduced the valgrind error with one of the job for Bug 691014. I should have a solution for that on Monday (26 April). Given that neither Ken nor I could reproduce the problem (even in valgrind), I'll ask Marcos to retest with his configuration when I have committed a fix.
(In reply to comment #4) > I may have reproduced the valgrind error with one of the job for Bug 691014. I > should have a solution for that on Monday (26 April). Given that neither Ken > nor I could reproduce the problem (even in valgrind), I'll ask Marcos to retest > with his configuration when I have committed a fix. 691014 is quite "apparent" on the mac pro: (gdb) r -sDEVICE=ppmraw -sOutputFile=foo.ppm CityMap-evince-pdftopdf.pdf The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /Users/henrys/ghostpdl_fresh/gs/debugobj/gs -sDEVICE=ppmraw -sOutputFile=foo.ppm CityMap-evince-pdftopdf.pdf GPL Ghostscript SVN PRE-RELEASE 8.72 (2010-02-11) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 Font --nostringval-- ( aliased from CairoFont-0-0 ) is being rendered with FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-0-0 ) is mapped to FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-1-0 ) is being rendered with FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-1-0 ) is mapped to FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-2-0 ) is being rendered with FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-2-0 ) is mapped to FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-3-0 ) is being rendered with FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-3-0 ) is mapped to FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-4-0 ) is being rendered with FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-4-0 ) is mapped to FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-5-0 ) is being rendered with FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-5-0 ) is mapped to FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-6-0 ) is being rendered with FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-6-0 ) is mapped to FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-7-0 ) is being rendered with FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-7-0 ) is mapped to FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-8-0 ) is being rendered with FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-8-0 ) is mapped to FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-9-0 ) is being rendered with FAPI=FreeType Font --nostringval-- ( aliased from CairoFont-9-0 ) is mapped t Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000802 0x0010b0cd in names_index (nt=0x147f034, pnref=0x2d5b130) at iname.c:271 (gdb) bt #0 0x0010b0cd in names_index (nt=0x147f034, pnref=0x2d5b130) at iname.c:271 #1 0x001bca93 in zFAPIrebuildfont (i_ctx_p=0x14a8184) at zfapi.c:1341 #2 0x000b2672 in call_operator (op_proc=0x1bc7e8 <zFAPIrebuildfont>, i_ctx_p=0x14a8184) at interp.c:118 #3 0x000b4e56 in interp (pi_ctx_p=0x1501a6c, pref=0xbfffe7a4, perror_object=0xbfffe960) at interp.c:1174 #4 0x000b2d5a in gs_call_interp (pi_ctx_p=0x1501a6c, pref=0xbfffe8a8, user_errors=1, pexit_code=0xbfffe968, perror_object=0xbfffe960) at interp.c:508 #5 0x000b2bb7 in gs_interpret (pi_ctx_p=0x1501a6c, pref=0xbfffe8a8, user_errors=1, pexit_code=0xbfffe968, perror_object=0xbfffe960) at interp.c:466 #6 0x000a64c6 in gs_main_interpret (minst=0x1501a18, pref=0xbfffe8a8, user_errors=1, pexit_code=0xbfffe968, perror_object=0xbfffe960) at imain.c:214 #7 0x000a701a in gs_main_run_string_end (minst=0x1501a18, user_errors=1, pexit_code=0xbfffe968, perror_object=0xbfffe960) at imain.c:526 #8 0x000a6ee2 in gs_main_run_string_with_length (minst=0x1501a18, str=0x1506c28 "<2f55736572732f68656e7279732f446f776e6c6f6164732f436974794d61702d6576696e63652d706466746f7064662e706466>.runfile", length=112, user_errors=1, pexit_code=0xbfffe968, perror_object=0xbfffe960) at imain.c:484 #9 0x000a6e4a in gs_main_run_string (minst=0x1501a18, str=0x1506c28 "<2f55736572732f68656e7279732f446f776e6c6f6164732f436974794d61702d6576696e63652d706466746f7064662e706466>.runfile", user_errors=1, pexit_code=0xbfffe968, perror_object=0xbfffe960) at imain.c:466 #10 0x000aa00b in run_string (minst=0x1501a18, str=0x1506c28 "<2f55736572732f68656e7279732f446f776e6c6f6164732f436974794d61702d6576696e63652d706466746f7064662e706466>.runfile", options=3) at imainarg.c:815 #11 0x000a9fbb in runarg (minst=0x1501a18, pre=0x586fe8 "", arg=0x1502608 "/Users/henrys/Downloads/CityMap-evince-pdftopdf.pdf", post=0x58b671 ".runfile", options=3) at imainarg.c:805 #12 0x000a9c93 in argproc (minst=0x1501a18, arg=0xbffff4cd "/Users/henrys/Downloads/CityMap-evince-pdftopdf.pdf") at imainarg.c:738 #13 0x000a8352 in gs_main_init_with_args (minst=0x1501a18, argc=4, argv=0xbffff3cc) at imainarg.c:215 #14 0x00002821 in main (argc=4, argv=0xbffff3cc) at gs.c:77
Revision 11125 (I hope!) should resolve this issue, but I'm passing it back to Marcos to retest with his configuration, since I couldn't be absolutely sure I'm seeing the same issue.
I can no longer reproduce this, either on my machine or Henry's MacPro. Closing as FIXED (apparently).