In test files fts_04xx.xps and fts_10xx.xps ghostxps hangs forever when drawing images. It appears to be stuck in deallocation. Valgrind reports more than 300000 errors of the following kind: ==3310== Conditional jump or move depends on uninitialised value(s) ==3310== at 0x80B7CDD: longest_match (deflate.c:1138) ==3310== by 0x80B8C7E: deflate_slow (deflate.c:1595) ==3310== by 0x80B7200: deflate (deflate.c:790) ==3310== by 0x8144928: s_zlibE_process (szlibe.c:67) ==3310== by 0x8136FEC: swritebuf (stream.c:893) ==3310== by 0x8136B3C: s_process_write_buf (stream.c:744) ==3310== by 0x8135FE7: s_filter_close (stream.c:335) ==3310== by 0x81361BC: sclose (stream.c:417) ==3310== by 0x813792F: s_close_filters (stream.c:1214) ==3310== by 0x8160CB6: psdf_end_binary (gdevpsdu.c:412) ==3310== by 0x8189D04: pdf_end_image_binary (gdevpdfj.c:446) ==3310== by 0x817688F: pdf_copy_color_data (gdevpdfb.c:427)
The warning about longest_match() can be safely ignored. See toolbin/vg_okay.supp # Zlib examines the data past the end of the buffer by design # to reduce the number of boundary checks. This doesn't have any # external effects.
Please post a gdb 'where' trace after interrupting the forever.
Profiling with Shark.app puts it spending 99.9% of time in pl_mem_node_remove after the interpreter instance has been deallocated. Here's a stack trace from gdb: 0x002f6683 in pl_mem_node_remove (mem=0x3e4800, addr=0x7b10810 "\f") at ../pl/plalloc.c:141 141 if ( current->next && (current->next->address == addr) ) { (gdb) bt #0 0x002f6683 in pl_mem_node_remove (mem=0x3e4800, addr=0x7b10810 "\f") at ../pl/plalloc.c: 141 #1 0x002f6cdb in pl_free_object (mem=0x3e4800, ptr=0x7b10818, cname=0x375134 "pdf_free_resource_objects") at ../pl/plalloc.c:337 #2 0x0016aa5b in cos_stream_release (pco=0x1115e18, cname=0x375134 "pdf_free_resource_objects") at ../gs/src/gdevpdfo.c:1228 #3 0x001687c2 in cos_release (pco=0x1115e18, cname=0x375134 "pdf_free_resource_objects") at ../ gs/src/gdevpdfo.c:205 #4 0x001687dd in cos_free (pco=0x1115e18, cname=0x375134 "pdf_free_resource_objects") at ../ gs/src/gdevpdfo.c:212 #5 0x00171b24 in pdf_free_resource_objects (pdev=0x7f3008, rtype=resourceXObject) at ../gs/src/ gdevpdfu.c:1161 #6 0x00148e7b in pdf_close (dev=0x7f3008) at ../gs/src/gdevpdf.c:1078 #7 0x0023ccc4 in gs_closedevice (dev=0x7f3008) at ../gs/src/gsdevice.c:508 #8 0x0023bb7a in gx_device_finalize (vptr=0x7f3008) at ../gs/src/gsdevice.c:51 #9 0x001460b4 in device_pdfwrite_finalize (vpdev=0x7f3008) at ../gs/src/gdevpdf.c:108 #10 0x002f6c94 in pl_free_object (mem=0x3e4800, ptr=0x7f3008, cname=0x388160 "pl_main_universe_dnit(gx_device)") at ../pl/plalloc.c:332 #11 0x0035f867 in pl_main_universe_dnit (universe=0xbfffecd0, err_str=0xbffff00c "( p") at ../pl/ plmain.c:572 #12 0x0035f3d8 in pl_main (argc=4, argv=0xbffffaf4) at ../pl/plmain.c:437 #13 0x003613c2 in main (argc=4, argv=0xbffffaf4) at ../pl/plmain.c:1246
This is probably due to an absurd number of small allocations. There is no memory discipline in pdfwrite in the absence of garbage collection. XPS, PCL, PXL and friends don't have gc. Running with the option -n should fix this unless you have bypassed the option in XPS somehow. This won't fix the root problem but should allow the job to run.
Note that switching XPS (and PCL) to using the 'chunk' memory allocator layer over the 'dumb' PCL allocator will probably fix this. I'm available to help on this if desired. It will drastically reduce round trips through the 'dumb' allocator.
Regarding #5... the allocator is not the issue. The problem is by default in debug mode pcl, xps, and pclxl maintain a list of unfreed allocations which it then reports at the end of the job, the performance problem is due to the list getting very long. We can fix that fairly easily and it does not effect production builds or runs that use the -n option, I wanted to point out that pdfwrite doesn't appear to do a great deal of deallocation. There is constant growth of memory with any job. I was hoping ken could look at the list of allocations at the end of any job and see if any of the outstanding allocations could be cleaned up (freed) without much effort.
I can look at the allocations, yes. I seem to remember Igor telling me that pdfwrite wasn't very good about cleaning its memory up. This will probably be a long term task, doing a bit here and there.
Bug still reproducible in Ghostscript 9.03
I've just been back to check this, and it looks like the memory cleanup work has solved the problem here. I can run a debug version of gxps with both the test files in a matter of a few seconds. Certainly no indication that gxps is 'hung'. The output isn't correct of course, but that's a different problem.