A bug report for 3 distinct bugs linked to small blocksize in frag_find

frag_find-bug_test.sh

#!/bin/sh

FF=frag_find
#FF=./frag_find/src/frag_find
TMP=/tmp
#TMP=.
dd if=/dev/zero of=$TMP/zero_block_512 bs=512 count=1
dd if=/dev/zero of=$TMP/zero_block_1k bs=512 count=2
dd if=/dev/zero of=$TMP/zero_block_256 bs=256 count=1

$FF $TMP/zero_block_1k $TMP/zero_block_512
#Works as expected

#
# Bug #1
$FF -b 256 $TMP/zero_block_1k $TMP/zero_block_512
#Uses blocksize 512 for master and report; does not find

#
# Bug #2
$FF -b 256 $TMP/zero_block_1k $TMP/zero_block_256
#Segmentation fault

#
# Bug #3
$FF -b 256 $TMP/zero_block_1k $TMP/zero_block_512
#Only prints image blocks 0-1, although 2-3 also match

#
# Clean
rm $TMP/zero_block_*

How two reproduce three bugs about small blocksize in frag_find

This gist presents simple ways to reproduce 2 distinct bugs in frag_find, both related to the global blocksize variable.

The first command works as expected: blocksize defaults to 512, and the two blocks composing the image file are found.

Bug 1

Report mentions using custom block size can lead to inconsistent results.

The same command with blocksize 256 does not find any of the four blocks composing the image file. Besides, as output shows, although image file parsing uses the custom blocksize, master file parsing and report printing both seem to be using default blocksize.

Bug 2

Report mentions using custom block size combined with a 1-block long (or less) master file can lead to program crash.

The second command with blocksize 256 demonstrates that behavior.

Bug 3

Report mentions using custom block size combined with a 2-block long (or more) master file can lead to incomplete filemap printing.

The third command with blocksize 256 demonstrates that behavior.