From patchwork Fri Feb 14 23:26:50 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Buettner X-Patchwork-Id: 1238427 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=BFfnMmpf; dkim-atps=neutral Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 48K8hl2l4Yz9sPk for ; Sat, 15 Feb 2020 10:28:54 +1100 (AEDT) Received: from localhost ([::1]:46646 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2kOA-0000Sd-TC for incoming@patchwork.ozlabs.org; Fri, 14 Feb 2020 18:28:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50008) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2kNu-0000SO-HJ for qemu-devel@nongnu.org; Fri, 14 Feb 2020 18:28:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2kNt-0004Z0-0g for qemu-devel@nongnu.org; Fri, 14 Feb 2020 18:28:33 -0500 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:43539 helo=us-smtp-delivery-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j2kNs-0004Yk-Tf for qemu-devel@nongnu.org; Fri, 14 Feb 2020 18:28:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581722911; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=zqAqgsDyJfdRbbxw4hBDvYNHFHYPCepiaSqrZ7CEBaM=; b=BFfnMmpfm5ctbNtr11vzTR2rRt6Ya7ZQvrpc7Ar9kwviQTBKnU2b0s/sMpetoyZaj32UFa h1MLlVhquf5ERsmvrIa6jHKSIHwAgYcewNLITKSrm2G7hh98PoNJpz69do2pW3T5svVg9e /0Iy0yNyZpg9hdnGFZBjNuFeDPzc3lk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-373-KAD2fTgyNZGuO3abQ7-kTQ-1; Fri, 14 Feb 2020 18:28:26 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 85B80100550E for ; Fri, 14 Feb 2020 23:28:25 +0000 (UTC) Received: from f31-1.lan (ovpn-116-54.phx2.redhat.com [10.3.116.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4DD048EA1B; Fri, 14 Feb 2020 23:28:25 +0000 (UTC) From: Kevin Buettner To: qemu-devel@nongnu.org Subject: [PATCH] Handle gdb.MemoryError exception in dump-guest-memory.py Date: Fri, 14 Feb 2020 16:26:50 -0700 Message-Id: <20200214232650.35381-1-kevinb@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: KAD2fTgyNZGuO3abQ7-kTQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 207.211.31.81 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Buettner Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" I recently investigated a bug in which the dump-guest-memory.py script sees a gdb.MemoryError exception while attempting to dump memory obtained from a QEMU core dump. (And, yes, dump-guest-core=on was specified in the -machine option of the QEMU invocation.) It turns out that memory region in question is not being placed in the core dump and, after stepping through the kernel core dumping code responsible for making this decision, it looks reasonable to me to not include that region in the core dump. The region in question consists of all zeros and, according to the kernel's logic, has never been written to. This commit makes a small change to the dump-guest-memory script to cause inaccessible memory to be dumped as zeroes. This avoids the exception and places the correct values in the guest memory dump. --- scripts/dump-guest-memory.py | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/scripts/dump-guest-memory.py b/scripts/dump-guest-memory.py index 4177261d33..fbdfba458b 100644 --- a/scripts/dump-guest-memory.py +++ b/scripts/dump-guest-memory.py @@ -539,7 +539,12 @@ shape and this command should mostly work.""" while left > 0: chunk_size = min(TARGET_PAGE_SIZE, left) - chunk = qemu_core.read_memory(cur, chunk_size) + try: + chunk = qemu_core.read_memory(cur, chunk_size) + except gdb.MemoryError: + # Consider blocks of memory absent from a core file + # as being zeroed. + chunk = bytes(chunk_size) vmcore.write(chunk) cur += chunk_size left -= chunk_size