The customer reported the following problem with Ghostscript 7.03 with the attached file (which I know we don't support anymore, but are willing to make an exception for this customer): Recently we experienced a hang in the parser when processing one report from a customer and the call stack is like the following. Can you shed some lights about what’s going on and possible resolution? refs_clear_marks(void * 0x01ea58b0, unsigned int 376, const gs_memory_struct_type_s * 0x2532cda0 _st_refs) line 137 gc_objects_clear_marks(chunk_s * 0x011d2410) line 595 + 21 bytes gs_gc_reclaim(vm_spaces_s * 0x00fab330, int 0) line 384 + 9 bytes context_reclaim(vm_spaces_s * 0x00fab330, int 0) line 288 + 14 bytes gs_vmreclaim(gs_dual_memory_s * 0x00fab32c, int 0) line 158 + 17 bytes ireclaim(gs_dual_memory_s * 0x00fab32c, int -1) line 80 + 13 bytes interp_reclaim(gs_context_state_s * * 0x2536b794, int -1) line 419 + 17 bytes gs_call_interp(gs_context_state_s * * 0x2536b794, ref_s * 0x01d8eb14, int 0, int * 0x01d8eb94, ref_s * 0x01d8eb8c) line 481 + 11 bytes gs_interpret(gs_context_state_s * * 0x2536b794, ref_s * 0x01d8eb14, int 0, int * 0x01d8eb94, ref_s * 0x01d8eb8c) line 447 + 25 bytes gs_main_interpret(gs_main_instance_s * 0x2536b590 the_gs_main_instance, ref_s * 0x01d8eb14, int 0, int * 0x01d8eb94, ref_s * 0x01d8eb8c) line 208 + 31 bytes gs_main_run_string_continue(gs_main_instance_s * 0x2536b590 the_gs_main_instance, const char * 0x01f82c90, unsigned int 32768, int 0, int * 0x01d8eb94, ref_s * 0x01d8eb8c) line 585 + 25 bytes
Created attachment 7300 [details] patch I found an issue in gsalloc.c which had been fixed: I tried the file with Ghostscript 7.07, the oldest version that I had pre-compiled, and the file causes it to hang. The next oldest release I have is 7.30 which works. I've attached a patch which solves the hang problem you are having with 7.07. If you have trouble applying it please try the replacing the gsalloc.c file with the one I've attached.
The customer then reported: The patch fixed the issue with one report, however, we still have similar issue with a larger report with 1000 pages. The call stack is like: gc_trace(gs_gc_root_s * 0x01d8e890, gc_state_s * 0x01d8e8ec, gc_mark_stack_s * 0x01d8e360) line 877 gs_gc_reclaim(vm_spaces_s * 0x01f3b330, int 0) line 330 + 20 bytes context_reclaim(vm_spaces_s * 0x01f3b330, int 0) line 288 + 14 bytes gs_vmreclaim(gs_dual_memory_s * 0x01f3b32c, int 0) line 158 + 17 bytes ireclaim(gs_dual_memory_s * 0x01f3b32c, int -1) line 80 + 13 bytes interp_reclaim(gs_context_state_s * * 0x2536b794, int -1) line 419 + 17 bytes gs_call_interp(gs_context_state_s * * 0x2536b794, ref_s * 0x01d8eb14, int 0, int * 0x01d8eb94, ref_s * 0x01d8eb8c) line 481 + 11 bytes gs_interpret(gs_context_state_s * * 0x2536b794, ref_s * 0x01d8eb14, int 0, int * 0x01d8eb94, ref_s * 0x01d8eb8c) line 447 + 25 bytes gs_main_interpret(gs_main_instance_s * 0x2536b590 the_gs_main_instance, ref_s * 0x01d8eb14, int 0, int * 0x01d8eb94, ref_s * 0x01d8eb8c) line 208 + 31 bytes gs_main_run_string_continue(gs_main_instance_s * 0x2536b590 the_gs_main_instance, const char * 0x02042c90, unsigned int 32768, int 0, int * 0x01d8eb94, ref_s * 0x01d8eb8c) line 585 + 25 bytes parserContinue(VistaContext_s * 0x012cbc9c, char * 0x02042c90, int 32768) line 268 + 27 bytes This problem file is to large to attach, it can be found on: alex-artifex.homeip.net in /home/support/692008/265794.v
Further information: Command line: "C:\gs\gs7.03\bin>gswin32c.exe -dNOPAUSE -sDEVICE=pswrite -sOutputFile=c:\temp.out.ps "F:\Jira\VP 1594\265794.v" Compiler: MS VC++ 6.0 Operating system: Windows 2003 Server Enterprise Edition SP2 Hardware: Intel Xeon processor 2.67GHz with 11.9GB memory
Ken, I've assigned this bug to you to see if you can duplicate it more reliably under windows than I can under Linux. With gs8.51 it completes without locking up around 75% of the time and with gs8.53 appears to work 100% of the time, but since it takes nearly 20 minutes to run it's hard isolate the revision that fixed the problem. I have tried running it through valgrind without success.
(In reply to comment #5) > Ken, I've assigned this bug to you to see if you can duplicate it more reliably > under windows than I can under Linux. > > With gs8.51 it completes without locking up around 75% of the time and with > gs8.53 appears to work 100% of the time, but since it takes nearly 20 minutes > to run it's hard isolate the revision that fixed the problem. I have tried > running it through valgrind without success. So I guess I have to use 8.51 ? Can you give me a revision number I can pull from Subversion ? I don't have a source copy of 8.51 lying around. Is the attached file the one which exhibits the problem, or do I need the 1000 page file ?
(In reply to comment #6) > > So I guess I have to use 8.51 ? Can you give me a revision number I can pull > from Subversion ? I don't have a source copy of 8.51 lying around. 8.51 is r5848 > > Is the attached file the one which exhibits the problem, or do I need the 1000 > page file ? You need the 1000 page file.
(In reply to comment #5) > Ken, I've assigned this bug to you to see if you can duplicate it more reliably > under windows than I can under Linux. > > With gs8.51 it completes without locking up around 75% of the time and with > gs8.53 appears to work 100% of the time, but since it takes nearly 20 minutes > to run it's hard isolate the revision that fixed the problem. I have tried > running it through valgrind without success. The 8.51 source does not include the 3rd party libraries (jpeg, jasper, jbig2, zlib, libpng) so I had to take copies of those from my HEAD revision. I then rebuilt and tested using the 1000 page file and the supplied command line. I've now run this 10 times (execution time is around 10 minutes) without seeing any hang at all.