Created attachment 19901 [details] Sample file Valgrind reports an error in _itoa_word() on the ps2write device.
Created attachment 19909 [details] Log file This is the log for the commit df537046c2130be285b213b5d0478159d1c5b16d . This bug report is about the first error in the logs. The rest are assumed to be duplicates or parts of the cascade.
Valgrind error occurs because of to the "bad op" error detected by internal checking. This problem can be reproduced in the current master version on ps2write device and pdfwrite device with CompatibilityLevel < 1.4 , So the bug is reclassified as a pdfwrite problem. ~/ghostpdl/debugbin/gs -dCompatibilityLevel=1.3 -sDEVICE=pdfwrite -o /dev/null plan06.pdf ~/ghostpdl/debugbin/gs -sDEVICE=ps2write -o /dev/null plan06.pdf GPL Ghostscript GIT PRERELEASE 9.54.0: ./base/gxclrast.c(2216): Bad op 0a band y0 = 0 file pos 3006531926 buf pos 3082/4096 0: 42 39 3e 42 39 3e 42 39 3e 42 10: 39 3e 42 39 3e 42 39 3e 42 39 20: 3e 42 39 3e 42 39 3e 42 39 3e ...
Testing with commit 81ed663a4 I notice it takes a LONG time, but completes without a problem. Command lines tested: -Z: -sDEVICE=ps2write -o x.ps Bug702954.pdf takes 26280 seconds and has 1349 bands. Increasing BufferSpace so there are fewer bands: -dBufferSpace=128m -Z: -sDEVICE=ps2write -o x.ps Bug702954.pdf takes 2031 seconds, writes a 7Gb clist temp file -- it has 97 bands. Reducing the resolution to a more reasonable level: -r300 -dBufferSpace=128m -Z: -sDEVICE=ps2write -o x.ps Bug702954.pdf takes 360 seconds, writes a 7Gb clist temp file (17 bands). Increasing the MaxBitmap to allow for full page mode: -r300 -dMaxBitmap=2g -Z: -sDEVICE=ps2write -o x.ps Bug702954.pdf takes 46 seconds and the max memory allocated was 448,894,207 bytes. I don't get any errors with a debug build or with a release build. The resolution causes a difference because the default resolution for the ps2write device and the pdfwrite device is 720 dpi. The ps2write needs to flatten the page to an image because the page has transparency, the same as the pdfwrite device when generating PDF at less than level 1.4. Closing as WORKSFORME. It could be that a previous version had a problem that has since been fixed. BTW, mutool draw -F ppm -o out.ppm -r300 Bug702954.pdf renders the page in 7 seconds.
This bug only occurs in debugvg or vg builds, even when they run without Valgrind. The problem is reproduced in the latest revision, fceb46d81b0 and the following command line: gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.3 -o /dev/null plan06.pdf
This problem occurs with BAND_LIST_STORAGE=memory. Since Valgrind builds set this flag, it also occurs in Valgrind builds.
Confirmed to still happen with commit 8608819c8531174290d6075ad5747bd0b0f32d4b with debugvg build.
See also #703592
Fixed in: commit cd0bf7a10ca59c538780ea52474fe798a352563a Author: Robin Watts <Robin.Watts@artifex.com> Date: Wed Oct 20 12:25:52 2021 +0100 Bug 702954: Fix 'bad clist operation'. When reading bytes from the clist, we calculate the number of bytes left in the memory stream, and clip the number of requested bytes to this value (so we don't overread). Unfortunately, we were calculating the number of bytes left in a 32 bit int, so if are (say) exactly 4Gig from the end of the stream, we think we have 0 bytes left.