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
Created attachment 4047 [details] 09-34.PS
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
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
*** Bug 689855 has been marked as a duplicate of this bug. ***
Ken, do you realize that this bug is still pending
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 ?
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...
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.
On my system, the segfault first shows at r7158, so it is a long standing problem.
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.
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.
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.
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.
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.
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) ...
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.
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.
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.
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.
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.