The file pcl5ccet/23-01.BIN has indeterminisms on pages 18, 19, and 21 when converted to pbmraw with banding by GhostPCL r10448 and earlier versions. The command line I'm using for testing: main/obj/pcl6 -sOutputFile=test1.pbm -dMaxBitmap=10000 \ -sDEVICE=pbmraw -r600 -dNOPAUSE ./23-01.BIN
Since the indeterminism is with banding, I will investigate this and will assign to another engineer if it is not a clist issue.
With a 32 bit build of GhostPCL the indeterminism on page 18 goes away, but those on page 19 and 21 continue.
Created attachment 5765 [details] screenshot.png Screenshot showing the differences between different runs highlighted in red.
Oops, I was using pnmsplit to determine which pages have issues and its 0 based, so add one to the page numbers listed in Comment #0 and #2.
*** Bug 691012 has been marked as a duplicate of this bug. ***
I have done some investigation into this using valgrind (on a 32bit Ubuntu linux vmware box). The vast majority of the valgrind warnings thrown up are due to reading uninitialised data in cf_encode_2d or s_CFE_process. The call sequence is something like: clist_fill_mask clist_change_bits cmd_put_bits cmd_compress_bitmap s_CFE_process cf_encode_2d The net problem is that clist_change_bits checks to see if a tile is in the cache, and if it isn't, uses clist_add_tile to copy it into the cache. This introduces padding bytes at the edge of the tile, which can be uninitialised. The compression code is unaware of this and tries to compress them anyway, hence giving valgrind warnings. These valgrind warnings are therefore false positives. Fixing them may not be essential (as they don't actually indicate true problems), but might be worthwhile as 1) it means that compression will be better, and 2) we'll get consistent results (in terms of memory used etc). I have a patch to solve the problem that I will attach in a moment.
Created attachment 6718 [details] patch.txt Simple patch to add a bytes_copy_rectangle_zero_padding function. Does the same as bytes_copy_rectangle, but zeros any padding bytes.
With the patch in place, this leaves a single reported valgrind problem: ==5150== Source and destination overlap in memcpy(0xbe91a594, 0xbe91a5d9, 218) ==5150== at 0x4026865: memcpy (mc_replace_strmem.c:497) ==5150== by 0x8123316: cmd_read_data (gxclrast.c:199) ==5150== by 0x8124E9E: clist_playback_band (gxclrast.c:1050) ==5150== by 0x812CDDE: clist_playback_file_bands (gxclread.c:835) ==5150== by 0x812CB24: clist_render_rectangle (gxclread.c:764) ==5150== by 0x812C82A: clist_rasterize_lines (gxclread.c:676) ==5150== by 0x812C3A3: clist_get_bits_rectangle (gxclread.c:567) ==5150== by 0x81407C9: clist_get_bits_rect_mt (gxclthrd.c:487) ==5150== by 0x82D0E7D: gx_default_get_bits (gdevdgbr.c:51) ==5150== by 0x811E752: gdev_prn_get_bits (gdevprn.c:1229) ==5150== by 0x81D04A6: pbm_print_page_loop (gdevpbm.c:709) ==5150== by 0x81D0685: pbm_print_page (gdevpbm.c:757) Looking at the code in clist_playback_band (line 1050) it does indeed look as if it's copying a potentially overlapping block from cbp to cbuf.data. I don't understand the code in this area well enough to know if this is really a sensible thing to do, but assuming it is, the fix is simply to change the two memcpy's in cmd_read_data to be memmoves.
With those 2 fixes in, repeated runs of the following command line given on a 32bit linux box give identical results: main/obj/pcl6 -sOutputFile=test1.pbm -dMaxBitmap=10000 \ -sDEVICE=pbmraw -r600 -dNOPAUSE ./23-01.BIN This does give a different result to: main/obj/pcl6 -sOutputFile=test1.pbm \ -sDEVICE=pbmraw -r600 -dNOPAUSE ./23-01.BIN though, presumably indicating a banded/non banded difference.
Changing bug title from: Regression: indeterminism in 23-01.BIN with banding to: Regression: banding/non-banding mismatch in 23-01.BIN.
patch.txt and the memcpy/memmove fixes are committed as revisions 11723 and 11724 respectively.
The banded/unbanded differences in this file are significant. Looks like patterns to me.
Can I have an updated screenshot of this problem, Marcos? I must be missing something, I just see minor shifts nothing like what you have in the screenshot.
I didn't say there were differences in banding vs. non-banding, that was Robin's comment. The screenshot showed an indeterminism that was fixed (see comment #9). I agree that the banding/non-banding are not significant and so am closing the bug.