Bryan, On Sat, Mar 26, 2022 at 2:00 AM Bryan Henderson <bry...@giraffe-data.com> wrote: > > I don't know familiar you are with debuggers, C, or C arithmetic, so I'm > attaching a diagnostic version of the program and will also explain where I > think the problem lies in case you want to investigate on your own. > > If you put this .c file in converter/other/pnmtopalm/ and rebuild and run the > 'palmtopnm' executable that results, it should detect the failure and write > some useful diagnostic messages. Tell me what happens.
Thanks ! Here is what I see on my local riscv64/chroot == palm-roundtrip.test == pamdepth: promoting from black and white to grayscale palmtopnm: Invalid Palm image input. Header says 30 bytes per row after uncompressing from 8-bit Packbits, but we counted 4294967069 bytes in a row, before we stopped processing the row pnmcolormap: making histogram... pnmcolormap: Scanning image 0 pnmcolormap: 20314 colors so far pnmcolormap: 20314 colors found pnmcolormap: choosing 256 colors... pnmremap: 256 colors found in colormap palmtopnm: Invalid Palm image input. Header says 228 bytes per row after uncompressing from 8-bit Packbits, but we counted 4294967044 bytes in a row, before we stopped processing the row palm-roundtrip.test: FAILURE Pay attention that I cannot do any kind of gdb locally: % gdb ./converter/other/pnmtopalm/palmtopnm [...] (gdb) r Starting program: /home/mathieu/debian/netpbm/converter/other/pnmtopalm/palmtopnm warning: Could not trace the inferior process. warning: ptrace: Function not implemented During startup program exited with code 127. > > The problem is in function 'readPackBitsRow16'. The variable 'j' is getting > too large -- absurdly large, apparently because a bit code that is supposed to > encode a negative signed integer is being interpreted as a positive unsigned > one somewhere. It should not be hard to pinpoint where the arithmetic is > generating such a a large number. > > -- > Bryan Henderson San Jose, California
