bin/55242: Strange gaps in 8.0 kdump -x output

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>Number:         55242
>Category:       bin
>Synopsis:       kdump -x output can include mysteriously blank lines
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 07 18:15:00 +0000 2020
>Originator:     Mouse
>Release:        NetBSD 8.0
>Organization:
	Dis-
>Environment:
System: NetBSD Aaeon.Rodents-Montreal.ORG 8.0 NetBSD 8.0 (MAQ) #1: Wed May 1 17:05:41 EDT 2019 mouse%Aaeon.Rodents-Montreal.ORG@localhost:/home/mouse/kbuild/MAQ amd64
Architecture: x86_64
Machine: amd64
>Description:
	When using kdump -x, I was surprised to see a blank line in the
	data:

        020   00 00 00 00 00 00 00 00  00 00 01 00 01 00 00 00 ................
        030   00 00 01 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
        040                                                    ................
        050   00 00 01 00 00 00 00 00  00 00 00 00 00 00 00 00 ................

	I found nothing in the manpage explaining this.  Staring at the
	source, I _think_ this indicates a single duplicate of the
	previous line; it's the "Only one duplicate, print line" code
	in hexdump_buf().  It appears to be trying to repeat the
	previous output line, but, because of the memset at the top of
	the containing loop, it generates a line of spaces instead.

>How-To-Repeat:
	ktrace and kdump such a case.  Here's a specific example:

	dd if=/netbsd bs=16 count=1 of=z
	cat z z z > z3
	ktrace dd bs=48 if=z3 of=/dev/null
	kdump -x

	Inspect kdump output.  I see (exact details may differ)

...
   532      1 dd       CALL  read(3,0x7f7ffd81f080,0x30)
   532      1 dd       GIO   fd 3 read 48 bytes
        000   7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00 .ELF............
        010                                                    .ELF............
        020   7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00 .ELF............
   532      1 dd       RET   read 48/0x30
...
   532      1 dd       GIO   fd 4 wrote 48 bytes
        000   7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00 .ELF............
        010                                                    .ELF............
        020   7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00 .ELF............
   532      1 dd       RET   write 48/0x30
...

>Fix:
	Based solely on reading the source, I suspect the simplest fix
	is to move the memset down to after the if (dupl > 3) { ... }
	block - to just before the for() loop - so that the previous
	line's text is still available for the "Only one duplicate"
	code to print.  (Testing such things for 8 is a bit difficult
	for me at the moment.)

	As a possible alternative, move this PR to doc-bug and document
	the current behaviour.  I prefer this alternative, which is why
	I marked this sw-bug.  (Ideally, the manpage should outline the
	duplicate-line compression behaviour - and, preferably, kdump
	should have an option to suppress it, a la hexdump -v.)