Bug 689864 - Regression: 09-34.PS core dumps with pdfwrite
Summary: Regression: 09-34.PS core dumps with pdfwrite
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Regression (show other bugs)
Version: master
Hardware: All All
: P1 critical
Assignee: Ken Sharp
URL:
Keywords:
: 689855 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-05-24 12:37 UTC by Marcos H. Woehrmann
Modified: 2008-12-19 08:31 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
f250.ps (521 bytes, application/postscript)
2008-06-07 09:29 UTC, Alex Cherepanov
Details
689864 (999 bytes, patch)
2008-06-10 05:11 UTC, Ken Sharp
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2008-05-24 12:37:51 UTC
I recently updated the nightly regression with some additional test files.  One of them, 09-34.PS, fails 
when writing a PDF file with gshead (r8772).  The command line I'm using:

  bin/gs -sDEVICE=pdfwrite -o 09-34.pdf ./09-34.PS


This happens on my MacBook Pro and casper.

Here's the output from my MacBook Pro:

marcos@macbookpro:[10]% ~/artifex/head/bin/gs -sDEVICE=pdfwrite -o 09-34.pdf ./09-34.PS
GPL Ghostscript SVN PRE-RELEASE 8.63 (2008-03-01)
Copyright (C) 2008 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Can't find (or can't open) font file n019004l.pfb.
Loading NimbusSanL-Bold font from %rom%Resource/Font/NimbusSanL-Bold... 2769708 1256036 
8069648 6773665 1 done.
% _Pg checksums collected from GPL Ghostscript SVN PRE-RELEASE version 3010 
9-34 SYNTAX 1 
Can't find (or can't open) font file n021003l.pfb.
Loading NimbusRomNo9L-Regu font from %rom%Resource/Font/NimbusRomNo9L-Regu... 2749612 
1238326 8190224 6410054 1 done.
Can't find (or can't open) font file n022024l.pfb.
Loading NimbusMonL-BoldObli font from %rom%Resource/Font/NimbusMonL-BoldObli... 2769708 
1328434 8190224 6513732 2 done.
Can't find (or can't open) font file n021023l.pfb.
Loading NimbusRomNo9L-ReguItal font from %rom%Resource/Font/NimbusRomNo9L-ReguItal... 
2769708 1349801 8190224 6511033 2 done.
Can't find (or can't open) font file n019023l.pfb.
Loading NimbusSanL-ReguItal font from %rom%Resource/Font/NimbusSanL-ReguItal... 2789804 
1426945 8190224 6511834 2 done.
9-34 SYNTAX 1 = 6551 Graphic 60 ms 
/9-34___Pg01 6551 def %matching 6551 
9-34 SYNTAX 2 
9-34 SYNTAX 2 = 6534 Graphic 60 ms 
/9-34___Pg02 6534 def %matching 6534 
9-34 SYNTAX 3 
9-34 SYNTAX 3 = 56860 Graphic 80 ms 
/9-34___Pg03 56860 def %matching 56860 
9-34 SYNTAX 4 
9-34 SYNTAX 4 = 14716 Graphic 100 ms 
/9-34___Pg04 14716 def %matching 14716 
9-34 SYNTAX 5 
9-34 SYNTAX 5 = 5411 Graphic 70 ms 
/9-34___Pg05 5411 def %matching 5411 
9-34 SYNTAX 6 
9-34 SYNTAX 6 = 28613 Graphic 30 ms 
/9-34___Pg06 28613 def %NOT matching 18936 
9-34 SYNTAX 7 
9-34 SYNTAX 7 = 38433 Graphic 90 ms 
/9-34___Pg07 38433 def %matching 38433 
9-34 SYNTAX 8 
9-34 SYNTAX 8 = 37162 Graphic 20 ms 
9-34 ILLEGAL 
9-34 ILLEGAL = 47583 Text 10 ms 
/9-34___Pg08 84745 def %matching 84745 
9-34 Special Test A1 
9-34 Special Test A1 = 0 Graphic 0 ms 
9-34 Special Test A2 
9-34 Special Test A2 = 0 Graphic 10 ms 
/9-34___Pg09 0 def %matching 0 
9-34 Special Test A3 
9-34 Special Test A3 = 0 Graphic 10 ms 
9-34 Special Test A4 
9-34 Special Test A4 = 0 Graphic 10 ms 
/9-34___Pg10 0 def %matching 0 
9-34 Special Test A5 
9-34 Special Test A5 = 0 Graphic 10 ms 
9-34 Special Test A6 
9-34 Special Test A6 = 0 Graphic 10 ms 
/9-34___Pg11 0 def %matching 0 
9-34 Special Test B1 
9-34 Special Test B1 = 0 Graphic 20 ms 
/9-34___Pg12 0 def %matching 0 
9-34 Special Test B2 
9-34 Special Test B2 = 0 Graphic 10 ms 
/9-34___Pg13 0 def %matching 0 
9-34 Special Test B3 
9-34 Special Test B3 = 0 Graphic 10 ms 
/9-34___Pg14 0 def %matching 0 
9-34 Special Test C1 
9-34 Special Test C1 = 0 Graphic 10 ms 
/9-34___Pg15 0 def %matching 0 
9-34 Special Test C2 
9-34 Special Test C2 = 0 Graphic 50 ms 
/9-34___Pg16 0 def %matching 0 
9-34 GRAPHIC STATE 1 
9-34 GRAPHIC STATE 1 = 0 Graphic 10 ms 
/9-34___Pg17 0 def %matching 0 
9-34 GRAPHIC STATE 2 
Can't find (or can't open) font file n022003l.pfb.
Loading NimbusMonL-Regu font from %rom%Resource/Font/NimbusMonL-Regu... 2870808 1532526 
8392044 7010206 3 done.
9-34 GRAPHIC STATE 2 = 0 Graphic 50 ms 
/9-34___Pg18 0 def %matching 0 
9-34 GLOBINT 
Bus error
Comment 1 Marcos H. Woehrmann 2008-05-24 12:38:38 UTC
Created attachment 4047 [details]
09-34.PS
Comment 2 Marcos H. Woehrmann 2008-05-24 12:44:19 UTC
The core dump happens a bit earlier on casper:

marcos@casper2:[11]% bin/gs -I../fonts -sDEVICE=pdfwrite -o test.pdf ./09-34.PS
GPL Ghostscript SVN PRE-RELEASE 8.63 (2008-03-01)
Copyright (C) 2008 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusSanL-Bold font from ../fonts/n019004l.pfb... 2726084 1259459 8069648 6770465 1 
done.
% _Pg checksums collected from GPL Ghostscript SVN PRE-RELEASE version 3010 
9-34 SYNTAX 1 
Loading NimbusRomNo9L-Regu font from ../fonts/n021003l.pfb... 2742748 1395551 8190224 
6871480 1 done.
Loading NimbusMonL-BoldObli font from ../fonts/n022024l.pfb... 2859892 1540257 8210320 
6902096 2 done.
Loading NimbusRomNo9L-ReguItal font from ../fonts/n021023l.pfb... 2997132 1687145 8210320 
6902782 2 done.
Loading NimbusSanL-ReguItal font from ../fonts/n019023l.pfb... 3114276 1791572 8210320 
6903468 2 done.
9-34 SYNTAX 1 = 6551 Graphic 110 ms 
/9-34___Pg01 6551 def %matching 6551 
9-34 SYNTAX 2 
9-34 SYNTAX 2 = 6534 Graphic 110 ms 
/9-34___Pg02 6534 def %matching 6534 
9-34 SYNTAX 3 
9-34 SYNTAX 3 = 56860 Graphic 150 ms 
/9-34___Pg03 56860 def %matching 56860 
9-34 SYNTAX 4 
9-34 SYNTAX 4 = 14716 Graphic 150 ms 
/9-34___Pg04 14716 def %matching 14716 
9-34 SYNTAX 5 
9-34 SYNTAX 5 = 5411 Graphic 100 ms 
/9-34___Pg05 5411 def %matching 5411 
9-34 SYNTAX 6 
9-34 SYNTAX 6 = 28613 Graphic 60 ms 
/9-34___Pg06 28613 def %NOT matching 18936 
9-34 SYNTAX 7 
9-34 SYNTAX 7 = 38433 Graphic 140 ms 
/9-34___Pg07 38433 def %matching 38433 
9-34 SYNTAX 8 
9-34 SYNTAX 8 = 37162 Graphic 40 ms 
9-34 ILLEGAL 
9-34 ILLEGAL = 47583 Text 30 ms 
/9-34___Pg08 84745 def %matching 84745 
9-34 Special Test A1 
9-34 Special Test A1 = 0 Graphic 10 ms 
9-34 Special Test A2 
9-34 Special Test A2 = 0 Graphic 20 ms 
/9-34___Pg09 0 def %matching 0 
9-34 Special Test A3 
9-34 Special Test A3 = 0 Graphic 20 ms 
9-34 Special Test A4 
9-34 Special Test A4 = 0 Graphic 20 ms 
/9-34___Pg10 0 def %matching 0 
9-34 Special Test A5 
9-34 Special Test A5 = 0 Graphic 20 ms 
9-34 Special Test A6 
9-34 Special Test A6 = 0 Graphic 20 ms 
/9-34___Pg11 0 def %matching 0 
9-34 Special Test B1 
9-34 Special Test B1 = 0 Graphic 30 ms 
/9-34___Pg12 0 def %matching 0 
9-34 Special Test B2 
9-34 Special Test B2 ioerror image * /HIVAL 1 def gs Dev_N250 setcolorspace [f 249 {dup} repeat] F250 
9-34 Special Test B2 = 9990 Graphic 20 ms 
/9-34___Pg13 9990 def %NOT matching 0 
9-34 Special Test B3 
9-34 Special Test B3 = 0 Graphic 0 ms 
/9-34___Pg14 0 def %matching 0 
9-34 Special Test C1 
9-34 Special Test C1 = 0 Graphic 30 ms 
/9-34___Pg15 0 def %matching 0 
9-34 Special Test C2 
9-34 Special Test C2 = 0 Graphic 100 ms 
/9-34___Pg16 0 def %matching 0 
9-34 GRAPHIC STATE 1 
9-34 GRAPHIC STATE 1 = 0 Graphic 20 ms 
/9-34___Pg17 0 def %matching 0 
9-34 GRAPHIC STATE 2 
Segmentation fault

Comment 3 Marcos H. Woehrmann 2008-05-24 20:47:42 UTC
Since I'm trying to win the award for the longest bug report comments here's another one.  This is 
valgrind output with -Z@$?

marcos@casper2:[6]% valgrind debugobj/gs -dNOPAUSE -sDEVICE=pdfwrite -o test.pdf -Z\@\$\? 
./09-34.PS
==14479== Memcheck, a memory error detector.
==14479== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==14479== Using LibVEX rev 1804, a library for dynamic binary translation.
==14479== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==14479== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==14479== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==14479== For more details, rerun with: -v
==14479== 
--14479-- DWARF2 CFI reader: unhandled CFI instruction 0:50
--14479-- DWARF2 CFI reader: unhandled CFI instruction 0:50
--14479-- DWARF2 CFI reader: unhandled CFI instruction 0:50
--14479-- DWARF2 CFI reader: unhandled CFI instruction 0:50
GPL Ghostscript SVN PRE-RELEASE 8.63 (2008-03-01)
Copyright (C) 2008 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Can't find (or can't open) font file n019004l.pfb.
Loading NimbusSanL-Bold font from %rom%Resource/Font/NimbusSanL-Bold... 2970668 1313966 
8049552 6761549 1 done.
% _Pg checksums collected from GPL Ghostscript SVN PRE-RELEASE version 3010 
9-34 SYNTAX 1 
Can't find (or can't open) font file n021003l.pfb.
Loading NimbusRomNo9L-Regu font from %rom%Resource/Font/NimbusRomNo9L-Regu... 2950572 
1299140 8190224 6409990 1 done.
Can't find (or can't open) font file n022024l.pfb.
Loading NimbusMonL-BoldObli font from %rom%Resource/Font/NimbusMonL-BoldObli... 2970668 
1386948 8190224 6513411 2 done.
Can't find (or can't open) font file n021023l.pfb.
Loading NimbusRomNo9L-ReguItal font from %rom%Resource/Font/NimbusRomNo9L-ReguItal... 
2970668 1410615 8190224 6510712 2 done.
Can't find (or can't open) font file n019023l.pfb.
Loading NimbusSanL-ReguItal font from %rom%Resource/Font/NimbusSanL-ReguItal... 2970668 
1482131 8190224 6511513 2 done.
9-34 SYNTAX 1 = 6551 Graphic 8310 ms 
/9-34___Pg01 6551 def %matching 6551 
9-34 SYNTAX 2 
9-34 SYNTAX 2 = 6534 Graphic 6140 ms 
/9-34___Pg02 6534 def %matching 6534 
9-34 SYNTAX 3 
9-34 SYNTAX 3 = 56860 Graphic 9890 ms 
/9-34___Pg03 56860 def %matching 56860 
9-34 SYNTAX 4 
9-34 SYNTAX 4 = 14716 Graphic 9910 ms 
/9-34___Pg04 14716 def %matching 14716 
9-34 SYNTAX 5 
9-34 SYNTAX 5 = 5411 Graphic 6120 ms 
/9-34___Pg05 5411 def %matching 5411 
9-34 SYNTAX 6 
==14479== Conditional jump or move depends on uninitialised value(s)
==14479==    at 0x401F292: bcmp (mc_replace_strmem.c:441)
==14479==    by 0x8429B1B: gx_hld_saved_color_equal (gxhldevc.c:115)
==14479==    by 0x82B9A48: pdf_set_drawing_color (gdevpdfg.c:467)
==14479==    by 0x82E7A02: pdf_prepare_text_drawing (gdevpdtt.c:301)
==14479==    by 0x82EC32F: pdf_text_process (gdevpdtt.c:2401)
==14479==    by 0x840E038: gs_text_process (gstext.c:544)
==14479==    by 0x8117E2A: op_show_continue (zchar.c:527)
==14479==    by 0x80E9ADC: call_operator (interp.c:111)
==14479==    by 0x80EBCF8: interp (interp.c:1158)
==14479==    by 0x80EA123: gs_call_interp (interp.c:496)
==14479==    by 0x80E9FB7: gs_interpret (interp.c:454)
==14479==    by 0x80DEF97: gs_main_interpret (imain.c:214)
==14479== 
==14479== Conditional jump or move depends on uninitialised value(s)
==14479==    at 0x401F292: bcmp (mc_replace_strmem.c:441)
==14479==    by 0x8429B1B: gx_hld_saved_color_equal (gxhldevc.c:115)
==14479==    by 0x82B9A48: pdf_set_drawing_color (gdevpdfg.c:467)
==14479==    by 0x82E7A44: pdf_prepare_text_drawing (gdevpdtt.c:301)
==14479==    by 0x82EC32F: pdf_text_process (gdevpdtt.c:2401)
==14479==    by 0x840E038: gs_text_process (gstext.c:544)
==14479==    by 0x8117E2A: op_show_continue (zchar.c:527)
==14479==    by 0x80E9ADC: call_operator (interp.c:111)
==14479==    by 0x80EBCF8: interp (interp.c:1158)
==14479==    by 0x80EA123: gs_call_interp (interp.c:496)
==14479==    by 0x80E9FB7: gs_interpret (interp.c:454)
==14479==    by 0x80DEF97: gs_main_interpret (imain.c:214)
==14479== 
==14479== Conditional jump or move depends on uninitialised value(s)
==14479==    at 0x401F292: bcmp (mc_replace_strmem.c:441)
==14479==    by 0x8429B1B: gx_hld_saved_color_equal (gxhldevc.c:115)
==14479==    by 0x82B9A48: pdf_set_drawing_color (gdevpdfg.c:467)
==14479==    by 0x82BD038: pdf_prepare_imagemask (gdevpdfg.c:1680)
==14479==    by 0x82BE5CB: pdf_begin_typed_image_impl (gdevpdfi.c:563)
==14479==    by 0x82BF4DE: pdf_begin_typed_image (gdevpdfi.c:833)
==14479==    by 0x82BF566: gdev_pdf_begin_typed_image (gdevpdfi.c:848)
==14479==    by 0x83FA454: gs_image_begin_typed (gsimage.c:228)
==14479==    by 0x811FFF8: zimage_setup (zimage.c:148)
==14479==    by 0x8120297: zimagemask1 (zimage.c:221)
==14479==    by 0x80E9ADC: call_operator (interp.c:111)
==14479==    by 0x80ECCDE: interp (interp.c:1534)
==14479== 
==14479== Conditional jump or move depends on uninitialised value(s)
==14479==    at 0x401F292: bcmp (mc_replace_strmem.c:441)
==14479==    by 0x8429B1B: gx_hld_saved_color_equal (gxhldevc.c:115)
==14479==    by 0x82B9A48: pdf_set_drawing_color (gdevpdfg.c:467)
==14479==    by 0x82B1D81: pdf_setfillcolor (gdevpdfd.c:106)
==14479==    by 0x82B46E8: gdev_pdf_fill_path (gdevpdfd.c:1061)
==14479==    by 0x844D331: gx_fill_path (gxpaint.c:49)
==14479==    by 0x84070E6: fill_with_rule (gspaint.c:329)
==14479==    by 0x8407150: gs_fill (gspaint.c:345)
==14479==    by 0x8121E8E: zfill (zpaint.c:25)
==14479==    by 0x80E9ADC: call_operator (interp.c:111)
==14479==    by 0x80EBCF8: interp (interp.c:1158)
==14479==    by 0x80EA123: gs_call_interp (interp.c:496)
9-34 SYNTAX 6 = 28613 Graphic 6130 ms 
/9-34___Pg06 28613 def %NOT matching 18936 
9-34 SYNTAX 7 
9-34 SYNTAX 7 = 38433 Graphic 7760 ms 
/9-34___Pg07 38433 def %matching 38433 
9-34 SYNTAX 8 
9-34 SYNTAX 8 = 37162 Graphic 1830 ms 
9-34 ILLEGAL 
9-34 ILLEGAL = 47583 Text 1280 ms 
/9-34___Pg08 84745 def %matching 84745 
9-34 Special Test A1 
9-34 Special Test A1 = 0 Graphic 690 ms 
9-34 Special Test A2 
9-34 Special Test A2 = 0 Graphic 960 ms 
/9-34___Pg09 0 def %matching 0 
9-34 Special Test A3 
9-34 Special Test A3 = 0 Graphic 1140 ms 
9-34 Special Test A4 
9-34 Special Test A4 = 0 Graphic 990 ms 
/9-34___Pg10 0 def %matching 0 
9-34 Special Test A5 
9-34 Special Test A5 = 0 Graphic 1410 ms 
9-34 Special Test A6 
9-34 Special Test A6 = 0 Graphic 910 ms 
/9-34___Pg11 0 def %matching 0 
9-34 Special Test B1 
9-34 Special Test B1 = 0 Graphic 1470 ms 
/9-34___Pg12 0 def %matching 0 
9-34 Special Test B2 
9-34 Special Test B2 = 0 Graphic 1250 ms 
GPL Ghostscript SVN PRE-RELEASE 8.63: src/ilocate.c(550): Bad object 0x5048ed8(4294967295),
==14479== 
==14479== Invalid read of size 4
==14479==    at 0x81298D6: ialloc_validate_object (ilocate.c:551)
==14479==    by 0x8129020: ialloc_validate_chunk (ilocate.c:305)
==14479==    by 0x8128D86: ialloc_validate_memory (ilocate.c:248)
==14479==    by 0x8128C4E: ialloc_validate_spaces (ilocate.c:218)
==14479==    by 0x8113B3F: ivalidate_clean_spaces (zvmem.c:56)
==14479==    by 0x8113E2D: zrestore (zvmem.c:120)
==14479==    by 0x80CF125: z2restore (zdevice2.c:319)
==14479==    by 0x80E9ADC: call_operator (interp.c:111)
==14479==    by 0x80ECCDE: interp (interp.c:1534)
==14479==    by 0x80EA123: gs_call_interp (interp.c:496)
==14479==    by 0x80E9FB7: gs_interpret (interp.c:454)
==14479==    by 0x80DEF97: gs_main_interpret (imain.c:214)
==14479==  Address 0xffffffff is not stack'd, malloc'd or (recently) free'd
==14479== 
==14479== Process terminating with default action of signal 11 (SIGSEGV)
==14479==  General Protection Fault
==14479==    at 0x81298D6: ialloc_validate_object (ilocate.c:551)
==14479==    by 0x8129020: ialloc_validate_chunk (ilocate.c:305)
==14479==    by 0x8128D86: ialloc_validate_memory (ilocate.c:248)
==14479==    by 0x8128C4E: ialloc_validate_spaces (ilocate.c:218)
==14479==    by 0x8113B3F: ivalidate_clean_spaces (zvmem.c:56)
==14479==    by 0x8113E2D: zrestore (zvmem.c:120)
==14479==    by 0x80CF125: z2restore (zdevice2.c:319)
==14479==    by 0x80E9ADC: call_operator (interp.c:111)
==14479==    by 0x80ECCDE: interp (interp.c:1534)
==14479==    by 0x80EA123: gs_call_interp (interp.c:496)
==14479==    by 0x80E9FB7: gs_interpret (interp.c:454)
==14479==    by 0x80DEF97: gs_main_interpret (imain.c:214)
==14479== 
==14479== ERROR SUMMARY: 2201 errors from 5 contexts (suppressed: 39 from 1)
==14479== malloc/free: in use at exit: 9,686,007 bytes in 495 blocks.
==14479== malloc/free: 5,641 allocs, 5,146 frees, 113,864,481 bytes allocated.
==14479== For counts of detected errors, rerun with: -v
==14479== searching for pointers to 495 not-freed blocks.
==14479== checked 16,555,416 bytes.
==14479== 
==14479== LEAK SUMMARY:
==14479==    definitely lost: 0 bytes in 0 blocks.
==14479==      possibly lost: 0 bytes in 0 blocks.
==14479==    still reachable: 9,686,007 bytes in 495 blocks.
==14479==         suppressed: 0 bytes in 0 blocks.
==14479== Rerun with --leak-check=full to see details of leaked memory.
Segmentation fault

Comment 4 Alex Cherepanov 2008-05-24 22:54:39 UTC
*** Bug 689855 has been marked as a duplicate of this bug. ***
Comment 5 Ray Johnston 2008-06-06 10:07:29 UTC
Ken, do you realize that this bug is still pending
Comment 6 Ken Sharp 2008-06-07 00:55:26 UTC
Yes Ray, its top of my list. I've been trying to tidy up the colour stuff to the
point where I could leave it without forgetting everything. Shouldn't be long
now and then I'll get to this.

I don't suppose anyone knows where the regression crept in ?
Comment 7 Ken Sharp 2008-06-07 03:15:06 UTC
Marcos, I'm sorry but I can't reproduce a crash on Windows using the current
HEAD revision. Neither release nor debug builds.

For me the operation completes and produces a PDF file. Admittedly the pattern
on the second to last page doesn't look correct, but there is no crash. In fact
I haven't been able to reproduce a crash with this file on any revision I've
tried (had a go at several revisions, in particular 8773->8776).

Given that I haven't changed pdfwrite for quite a while, is it possible this is
something to do with Leonardo's work on patterns ? It seems unlikely but... If I
can't reproduce the crash, fixing it is going to be tricky...
Comment 8 Alex Cherepanov 2008-06-07 09:29:50 UTC
Created attachment 4082 [details]
f250.ps

I can reproduce the crash under debugger but get an infinite loop
without debugger. Commenting out the following line from the original test file

clears all problems.
  (/HIVAL 1 def gs Dev_N250 setcolorspace [f 249 {dup} repeat] F250)

Attached is a sample file that exercises DeviceN with variable number of
components, however the file fails with different errors: pdfwrit faills
into an infinite loop, other devices fails with rangecheck. Rendering is
rather slow at N = 8 . So the loops may be not infinite.
Comment 9 Ralph Giles 2008-06-07 12:29:06 UTC
On my system, the segfault first shows at r7158, so it is a long standing problem.
Comment 10 Ken Sharp 2008-06-09 00:34:42 UTC
Thanks for all the input everyone. From Alex's discovery and the original report
from Marcos, it looks to me like memory corruption of some sort. I notice its
with the massive 250 ink DeviceN Genoa test which is probably a clue...

I'm trying some more ways to get a problem to exhibit under a debugger for me,
but without success so far. Its probably going to depend on just where the
corruption occurs.

I'll start off by reviewing the pdfwrite code for DeviceN inks looking for any
likely candidates.

Thanks all.
Comment 11 Ken Sharp 2008-06-09 08:52:37 UTC
I don't have a solution for this, nor yet a complete understanding of the issue,
however....

The current colour space code for DeviceN converts the tint transform into a
PostScript Function, starting with a type 4 (calculator). 

However Alex's file can't be converted to a calculator function, because it
needs to do a name lookup on /N. Since that fails, we attempt to convert it to a
sampled function (type 0). This also fail,s because we don't permit more than 16
inputs on a sampled function.

The colour space code then falls back to a 'panic' situation, and replaces the
tint transform with an empty procedure '{}', which it then converts into a type
4 function.

When we actually try to use this function in the rendering code, something seems
to realise that there's a problem, and we get a rangecheck error. I'm puzzled as
to why this does not apparently raise a rangecheck error with the original Genoa
file.

Anyway, the pdfwrite code assumes everything is just fine and writes out the
function, which is why it does not produce a typecheck error. 

I'm not sure yet if this is related to the actual crash problem though it may be.

Note that the result of rendering the null function would be wrong, as would a
PDF file containing this function. Although the rendering could probably be
fixed by using the tint transform function as required, this is not an option
for pdfwrite as PDF files must use functions.

I think the proper solution for pdfwrite is going to have to be to raise an
error, for now at least.
Comment 12 Ray Johnston 2008-06-09 09:04:58 UTC
I think it is acceptable to raise a 'rangecheck' error for this kind of
severe DeviceN color that has BOTH a tint transform that is not within the
Type 4 PS subset, and that has more than 16 actual components.

In the 'real world' even on files that use more than 16 spot colors, we've never
seen more than 5 components in the colorspace at once. Usually it's just CMYK
or a DeviceN colorspace with a single spot color. Even then I suspect that most
tint transform functions are amenable to Type 4 coding.

Obviously, any PDF input file would be fine since the tint transform is a valid
function, and PDF is rapidly supplanting PS for high end graphics documents.
Comment 13 Henry Stiles 2008-06-09 09:46:12 UTC
From the valgrind output it seems we have memory corruption so Leo should have a
look before you make the change.  I imagine the suggested fix would just obscure
the underlying gs memory problem.  Maybe I don't understand something.
Comment 14 Alex Cherepanov 2008-06-09 10:05:55 UTC
There's no N variable in 09-34.PS - the value is hardcoded. 
Try to use //N instead of N in my file.

The error in gx_hld_saved_color_equal() is likely to be caused by
color values calculated from uninitialized data. A similar error
occurs in many files and I have a patch for it deep in the code review
queue. I don't think it's serious.
Comment 15 Henry Stiles 2008-06-09 10:09:48 UTC
I was referring to:

GPL Ghostscript SVN PRE-RELEASE 8.63: src/ilocate.c(550): Bad object
0x5048ed8(4294967295),
==14479== 
==14479== Invalid read of size 4
==14479==    at 0x81298D6: ialloc_validate_object (ilocate.c:551)
==14479==    by 0x8129020: ialloc_validate_chunk (ilocate.c:305)
==14479==    by 0x8128D86: ialloc_validate_memory (ilocate.c:248)
...
Comment 16 Ken Sharp 2008-06-10 01:01:29 UTC
Hmm, lots of activity while I was asleep :-)

To clear things up. Alex's file exhibits a different problem to the 09-34.ps
file. This issue is basically that we can't render a DeviceN space with more
than 16 inks if the tint transform can't be represented as a PostScript
calculator function. (As Ray rightly points out in comment #12, this isn't a
problem with PDF where the tint transform is already a function)

For rendering devices the problem is detected when the function is executed as
part of painting an object, and a rangecheck is raised. Since pdfwrite doesn't
execute the function, it doesn't raise this error. This is the first issue,
pdfwrite should not attempt to write this fnction out, but should raise an
error, just like when rendering. I think I can see an easy way to detect the
problem and do this.

The reason pdfwrite enters an infinte loop is because it is trying to write an
empty stream (representing the function) to the PDF file. This is the second
error, and I need to do some more debugging to work out what to do about this. 

Fixing the first error would mask the second one, and I'd like to fix that
first. I think it is possible to write an empty function dictionary legally (eg
/Separation colour with a DeviceGray fallback).

Alex is correct in comment #14 that the use of the named variable 'N' is what
causes the problem, and the fact that the 09-34.ps file has the number
hard-coded explains why this file renders correctly rather than raising a
rangecheck error. (with Alex's file we can't represent the tint transform as a
type 4 function, the Genoa file we can)


Neither of these issues (alas) relates to the original problem with 09-34.ps. I
can now reproduce this under a debugger, using a release build with added
debugging information. Fixing Alex's file (which needs to be done anyway) will
have no effect on the issue with the Genoa file.

The problem does definitely appear to be memory corruption, the valgrind output
Henry mentions in comments #13 and #15 seems to be pretty clear on this. The
problem exhibits either in a restore at the end of page (as per the valgrind
output) or when the garbage collector runs. Precisely where the error occurs
seems non-deterministic, as might be expected for a memory corruption problem,
and explains the difficulty I've had reproducing it...

I did a quick review of the pdfwrite code yesterday and couldn't see anything
obviously incorrect, but I'll look further today. Ralph suggests this problem
has existed for some time (comment #9), so it may not be a regression at all,
but a long-standing problem never noticed before. It is not a Pattern problem as
I first suspected, and I think it would have exhibited in rendering before now
if the problem was outside pdfwrite, so I suspect it really is a memory
corruption caused by pdfwrite. I'll look at revision 7158 today, I spent
yesterday getting a grip on the problem and trying to figure out why Alex's file
caused a different set of issues.....

Thanks again for the input everyone.
Comment 17 Ken Sharp 2008-06-10 05:11:31 UTC
Created attachment 4088 [details]
689864

I believe I have the answer. The source of the crash is actually in the PNG
encode filter, and is the same problem in Alex's test file as in the original
Genoa file (thanks Alex).

The PNG filter has a maximum of 60 colourants (spngpx.h), and the PNG stream
structure contains a fixed buffer ('prev') whose size is related to this. The
PDF code doesn't test the number of colourants before setting up the PNG encode
filter, and the filter itself doesn't test the number of colourants in use.

As a result, when we write 250 inks to it, it overflows the fixed buffer and
causes memory corruption. One of the first things to go is usually the parent
structure, which can cause an infinite loop. If it doesn't cause an infinite
loop, then the restore or garbage collection will catch grief instead.

I could fix this by increasing the number of colourants in the PNG filter, or
by checking the number of inks against the maximum permitted number of inks in
PNG in the pdfwrite code, and selecting a different compression. 

However, the PDF spec states that Acrobat has an architectural limit of 32 inks
in a DeviceN space. So I've chosen to limit the pdfwrite output of DeviceN
spaces to a limit of 32 inks. (GS also won't render a PDF file with a 250 ink
DeviceN space) 

This prevents the crash and mimics Acrobat behaviour. However it would probably
be ideal if the PNG encoder checked the number of supplied colourants against
the maximum to prevent this recurring under other circumstances, so I've done
that too.

FWIW it looks like this was introduced way back in November 2006 when the
maximumm number of DeviceN inks was raised to 250 specifically to cater for the
Genoa files ;-)

Patch attached, if anyone sees a problem with either of these changes, please
let me know.
Comment 18 Alex Cherepanov 2008-06-11 17:57:19 UTC
I vote for the buffer increase.

Ghostscript need not to be restricted by implementation limits of Acrobat.
One more file from the CET suite we accept is one less issue to explain to the
customer and handle specially in internal testing.

Although CET suite is not designed for the testing of Distiller-like
products, matching PDF and PS rasters for all CET files will thoroughly
exercise pdfwrite device.
Comment 19 Ken Sharp 2008-06-12 00:53:37 UTC
In the absence of dissenting opinion I'll increase the maximum number of inks in
the Flate encoder (I think it is flate, not PNG), and therefore the buffer size.
I will still implement a check in the encocder to make sure that we aren't
overflowing the maximum number of inks, though, to prevent this problem
recurring. I won't limit the pdfwrite output to 32 inks. 

Alex, when I tried this earlier GS gave up on the resulting PDF file as well. At
the moment I'm getting an '/undefined in --run--' error, and an older version of
GS (8.60) gives me a '/rangecheck in --filter--' error. The latter isn't
surprising, as it would presumably only allow 60 inks. Which is amusing as it
suggests the Flate decoder already check against the maximum....

In fact, I can't test the output at all, because I can't find any PDF reader
which is prepared to cope with a DeviceN array containing this many inks, they
all seem to respect the Acrobat implementation limit.

Comment 20 Ken Sharp 2008-07-07 01:58:37 UTC
This patch

http://ghostscript.com/pipermail/gs-cvs/2008-July/008405.html

resolves the crash. I can't check the output PDF file as I can't find a PDF
reader which will open a file with a DeviceN space containing more than 32 inks.