Summary: | Regression: seg fault reading GhostPCL produced PDF file at 600 dpi | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Marcos H. Woehrmann <marcos.woehrmann> |
Component: | PDF Interpreter | Assignee: | Ray Johnston <ray.johnston> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | alex, henry.stiles, ken.sharp |
Priority: | P4 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | All | ||
Customer: | Word Size: | --- | |
Attachments: |
experimental patch
Minimal sample file. Another approach |
Description
Marcos H. Woehrmann
2010-12-08 18:19:32 UTC
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 *** |