Attempting to read the attached PDF file at 600 dpi produces seg fault with Ghostscript head (r11938) on page 24. This is a regression, starting with r9288: r9288 | leonardo | 2008-12-13 12:05:37 -0800 (Sat, 13 Dec 2008) | 26 lines Enhancement (graphics) : Implement new device virtual method 'fillpage'. The command line's I'm using for testing: bin/gs -r600 -dFirstPage=24 -sDEVICE=ppmraw -o test.ppm ./test.pdf Note that this is a GhostPCL produced PDF file, it was generated by the following command line: main/obj/pcl6 -r600 -sDEVICE=pdfwrite -sOutputFile=test.pdf -dNOPAUSE ./c320.bin
Created attachment 7012 [details] test.pdf
Created attachment 7014 [details] test2.pdf The attached PDF file, generated by GhostPDL from C320.bin, fails in the same way as test.pdf, but on page 13.
In case it's not clear: c320.bin == tests_private/xl/pcl6cet/c320.bin C320.bin == tests_private/xl/pcl6cet3.0/C320.bin
Here is the valgrind output from test.pdf: marcos@amd64:[38]% valgrind head/debugobj/gs -Z@\?\$ -r600 -dFirstPage=24 -sDEVICE=ppmraw -o test.ppm ./test.pdf ==13804== Memcheck, a memory error detector ==13804== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==13804== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==13804== Command: head/debugobj/gs -Z@?$ -r600 -dFirstPage=24 -sDEVICE=ppmraw -o test.ppm ./test.pdf ==13804== GPL Ghostscript SVN PRE-RELEASE 9.01 (2010-09-14) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 24 through 25. Page 24 ==13804== Jump to the invalid address stated on the next line ==13804== at 0x0: ??? ==13804== by 0x751AD9: clist_playback_file_bands (gxclread.c:835) ==13804== by 0x751690: clist_render_rectangle (gxclread.c:764) ==13804== by 0x751327: clist_rasterize_lines (gxclread.c:676) ==13804== by 0x750E2B: clist_get_bits_rectangle (gxclread.c:567) ==13804== by 0x7677BD: clist_get_bits_rect_mt (gxclthrd.c:512) ==13804== by 0xA36C51: gx_default_get_bits (gdevdgbr.c:51) ==13804== by 0x73EFEF: gdev_prn_get_bits (gdevprn.c:1230) ==13804== by 0x823430: pbm_print_page_loop (gdevpbm.c:709) ==13804== by 0x823ED5: ppm_print_page (gdevpbm.c:962) ==13804== by 0x73E155: gx_default_print_page_copies (gdevprn.c:835) ==13804== by 0x73DEB4: gdev_prn_output_page (gdevprn.c:771) ==13804== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==13804== ==13804== ==13804== Process terminating with default action of signal 11 (SIGSEGV) ==13804== Bad permissions for mapped region at address 0x0 ==13804== at 0x0: ??? ==13804== by 0x751AD9: clist_playback_file_bands (gxclread.c:835) ==13804== by 0x751690: clist_render_rectangle (gxclread.c:764) ==13804== by 0x751327: clist_rasterize_lines (gxclread.c:676) ==13804== by 0x750E2B: clist_get_bits_rectangle (gxclread.c:567) ==13804== by 0x7677BD: clist_get_bits_rect_mt (gxclthrd.c:512) ==13804== by 0xA36C51: gx_default_get_bits (gdevdgbr.c:51) ==13804== by 0x73EFEF: gdev_prn_get_bits (gdevprn.c:1230) ==13804== by 0x823430: pbm_print_page_loop (gdevpbm.c:709) ==13804== by 0x823ED5: ppm_print_page (gdevpbm.c:962) ==13804== by 0x73E155: gx_default_print_page_copies (gdevprn.c:835) ==13804== by 0x73DEB4: gdev_prn_output_page (gdevprn.c:771) ==13804== ==13804== HEAP SUMMARY: ==13804== in use at exit: 9,405,491 bytes in 648 blocks ==13804== total heap usage: 1,869 allocs, 1,221 frees, 21,621,156 bytes allocated ==13804== ==13804== LEAK SUMMARY: ==13804== definitely lost: 0 bytes in 0 blocks ==13804== indirectly lost: 0 bytes in 0 blocks ==13804== possibly lost: 9,402,771 bytes in 642 blocks ==13804== still reachable: 2,720 bytes in 6 blocks ==13804== suppressed: 0 bytes in 0 blocks ==13804== Rerun with --leak-check=full to see details of leaked memory ==13804== ==13804== For counts of detected and suppressed errors, rerun with: -v ==13804== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 6) Segmentation fault marcos@amd64:[39]% The test2.pdf command fails in the same way.
Created attachment 7019 [details] experimental patch The crash happens because "clip list accumulator" device has no "fillpage" method. The work around is easy: just use "fill_rectangle" when "fillpage" is not defined but I have no opinion whether "clip list accumulator" should have this this method and why it's different from "fill_rectangle".
(In reply to comment #5) > Created an attachment (id=7019) [details] > experimental patch > > The crash happens because "clip list accumulator" device has no "fillpage" > method. The work around is easy: just use "fill_rectangle" when "fillpage" > is not defined but I have no opinion whether "clip list accumulator" should > have this this method and why it's different from "fill_rectangle". Shouldn't the clip list accumulator just forward the fillpage call like other forwarding devices? What events conspire to make the clip list accumulator receive a fillpage device call? Odd this doesn't happen in a single other pdf test. Maybe Ken should look at the PDF. You can assign it to me, but I was hoping you or Ken could look at it a bit more (see the questions above) so I understand the issues better.
Created attachment 7048 [details] Minimal sample file.
Created attachment 7049 [details] Another approach Just implement fillpage method.
The clist writer is writing a 0 area rectangle which is subsequently interpreted as a fillpage device call upon band playback.
*** This bug has been marked as a duplicate of bug 691596 ***