NetBSD Problem Report #55242
From mouse@Stone.Rodents-Montreal.ORG Thu May 7 18:14:28 2020
Return-Path: <mouse@Stone.Rodents-Montreal.ORG>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 1A1AE1A9213
for <gnats-bugs@gnats.NetBSD.org>; Thu, 7 May 2020 18:14:28 +0000 (UTC)
Message-Id: <202005071814.OAA09309@Stone.Rodents-Montreal.ORG>
Date: Thu, 7 May 2020 14:14:24 -0400 (EDT)
From: Mouse <mouse@Rodents-Montreal.ORG>
Reply-To: mouse@Rodents-Montreal.ORG
To: gnats-bugs@NetBSD.org
Subject: Strange gaps in 8.0 kdump -x output
X-Send-Pr-Version: 3.95
>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:/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.)
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.