If somebody uses huge halftone thresholds (i.e. array 1200x1200), he will have problems with memory leakage -- in case of larger images it leads to improper output (only part of image is rendered). I don't attach test file because this error appears only in case of realy big halftones and images. If it will be needed I try hard to prepare reasonably big test set. I tried to debug problem and I think I found place where problem arises. In gxdhtserial.c in procedure gx_ht_read_and_install is called procedure gx_ht_read_component (which allocates memory for halftone -- in my case it's about 4*11MB). Next is called gx_imager_dev_ht_install, which in turn calls gx_ht_copy_ht_order (according to comment in gx_imager_dev_ht_install components should be duplicated, but without levels and bit_data arrays, although gx_ht_copy_ht_order allocates copy of this arrays!) After rendering a band, in function gx_device_halftone_release is called procedure gx_ht_order_release which releases memory allocated by gx_imager_dev_ht_install but not(!) this allocated by gx_ht_read_component. Below I attach (filtered to important calls) output of GhostScript debug session (-ZAa): gx_ht_read_compontent: [a+]gs_malloc(large object chunk)(11520028) = 0xa58b7020: OK [a+]gs_malloc(large object chunk)(11520028) = 0xa4dba020: OK [a+]gs_malloc(large object chunk)(11520028) = 0xa42bd020: OK [a+]gs_malloc(large object chunk)(11520028) = 0xa37c0020: OK gx_ht_copy_ht_order: [a+]gs_malloc(large object chunk)(11520028) = 0xa2cc3020: OK [a+]gs_malloc(large object chunk)(11520028) = 0xa21c6020: OK [a+]gs_malloc(large object chunk)(11520028) = 0xa16c9020: OK [a+]gs_malloc(large object chunk)(11520028) = 0xa0bcc020: OK [a+]gs_malloc(large object chunk)(182428) = 0x91558b8: OK [a8:+b.]alloc_ht_cache(bits) (182400) = 0x91558d4 [a+]gs_malloc(large object chunk)(182428) = 0x9182170: OK [a8:+b.]alloc_ht_cache(bits) (182400) = 0x918218c [a+]gs_malloc(large object chunk)(182428) = 0x91aea28: OK [a8:+b.]alloc_ht_cache(bits) (182400) = 0x91aea44 [a+]gs_malloc(large object chunk)(182428) = 0x91db2e0: OK [a8:+b.]alloc_ht_cache(bits) (182400) = 0x91db2fc and release: [a8:-oL]free_ht_cache(bits) bytes(182400) 0x91558d4 [a-]gs_free(alloc_free_chunk(data)) 0x91558b8(182428) [a8:-oL]gx_ht_order_release(bit_data) bytes(11520000) 0xa2cc303c [a-]gs_free(alloc_free_chunk(data)) 0xa2cc3020(11520028) [a8:-oL]free_ht_cache(bits) bytes(182400) 0x918218c [a-]gs_free(alloc_free_chunk(data)) 0x9182170(182428) [a8:-oL]gx_ht_order_release(bit_data) bytes(11520000) 0xa21c603c [a-]gs_free(alloc_free_chunk(data)) 0xa21c6020(11520028) [a8:-oL]free_ht_cache(bits) bytes(182400) 0x91aea44 [a-]gs_free(alloc_free_chunk(data)) 0x91aea28(182428) [a8:-oL]gx_ht_order_release(bit_data) bytes(11520000) 0xa16c903c [a-]gs_free(alloc_free_chunk(data)) 0xa16c9020(11520028) [a8:-oL]free_ht_cache(bits) bytes(182400) 0x91db2fc [a-]gs_free(alloc_free_chunk(data)) 0x91db2e0(182428) [a8:-oL]gx_ht_order_release(bit_data) bytes(11520000) 0xa0bcc03c [a-]gs_free(alloc_free_chunk(data)) 0xa0bcc020(11520028)
The sample file is always handy. At least it provides the exact content of the halftone and image dictionaries. The tracker accepts up to 20M. Larger files can be split into several chunks or put on FTP for download.
Created attachment 3716 [details] Test file Attached is (gziped) file, which include big halftone tile and low resolution image. When processed by Ghostscript command: gs -ZAa -dBATCH -dNOPAUSE -r2400 -sDEVICE=bitcmyk -sOutputFile=kubek-test.bit kubek-test.ps 2> trace.txt on Linux (Ubuntu 7.10, kernel 2.6.22) with 1GB physical memory, properly renders about top 2cm of image (which have size 70x50cm) -- below is a white page with few random lines (caused -- in my opinion -- by bad allocating of halftone memory). Remark: Low resolution of image, and sign in halftone cell are introduced purposely.
Restored the 'normal' severity for this bug. voipas@gmail.com please do not edit bugs which do not belong to you, in particular do not alter the importance of bugs this is assessed by Artifex.
Ran this with current head and memento. I see no signs of memory leaks. GPL Ghostscript GIT PRERELEASE 9.27 (2018-11-20) Copyright (C) 2018 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Total memory malloced = 70701432411 bytes Peak memory malloced = 184840063 bytes 212018 mallocs, 212018 frees, 0 reallocs Average allocation size 333469 bytes