[Qemu-devel] [PATCH] dump-guest-memory: more descriptive lookup_type failure

[Qemu-devel] [PATCH] dump-guest-memory: more descriptive lookup_type failure

[Andrew Jones]

We've seen a few reports of

 (gdb) source /usr/share/qemu-kvm/dump-guest-memory.py
 Traceback (most recent call last):
   File "/usr/share/qemu-kvm/dump-guest-memory.py", line 19, in <module>
     UINTPTR_T = gdb.lookup_type("uintptr_t")
 gdb.error: No type named uintptr_t.

This occurs when symbols haven't been loaded first, i.e. neither a
QEMU binary was loaded nor a QEMU process was attached first. Let's
better inform the user of how to fix the issue themselves in order
to avoid more reports.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 scripts/dump-guest-memory.py | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/dump-guest-memory.py b/scripts/dump-guest-memory.py
index 51acfcd0c053..e56fff6d7e82 100644
--- a/scripts/dump-guest-memory.py
+++ b/scripts/dump-guest-memory.py
@@ -16,7 +16,11 @@ the COPYING file in the top-level directory.
 import ctypes
 import struct
 
-UINTPTR_T = gdb.lookup_type("uintptr_t")
+try:
+    UINTPTR_T = gdb.lookup_type("uintptr_t")
+except Exception as inst:
+    raise gdb.GdbError("Symbols must be loaded prior to sourcing dump-guest-memory.\n"
+                       "Symbols may be loaded by first 'attach'ing a QEMU process id or by 'load'ing a QEMU binary.")
 
 TARGET_PAGE_SIZE = 0x1000
 TARGET_PAGE_MASK = 0xFFFFFFFFFFFFF000
-- 
2.13.6

Re: [Qemu-devel] [PATCH] dump-guest-memory: more descriptive lookup_type failure

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20180314142133.14166-1-drjones@redhat.com
Subject: [Qemu-devel] [PATCH] dump-guest-memory: more descriptive lookup_type failure

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
    echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
    if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
        failed=1
        echo
    fi
    n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]               patchew/20180314142133.14166-1-drjones@redhat.com -> patchew/20180314142133.14166-1-drjones@redhat.com
Switched to a new branch 'test'
8dba220694 dump-guest-memory: more descriptive lookup_type failure

=== OUTPUT BEGIN ===
Checking PATCH 1/1: dump-guest-memory: more descriptive lookup_type failure...
WARNING: line over 80 characters
#34: FILE: scripts/dump-guest-memory.py:22:
+    raise gdb.GdbError("Symbols must be loaded prior to sourcing dump-guest-memory.\n"

ERROR: line over 90 characters
#35: FILE: scripts/dump-guest-memory.py:23:
+                       "Symbols may be loaded by first 'attach'ing a QEMU process id or by 'load'ing a QEMU binary.")

total: 1 errors, 1 warnings, 12 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org

Re: [Qemu-devel] [PATCH] dump-guest-memory: more descriptive lookup_type failure

[Janosch Frank]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

On 14.03.2018 15:21, Andrew Jones wrote:
> We've seen a few reports of
> 
>  (gdb) source /usr/share/qemu-kvm/dump-guest-memory.py
>  Traceback (most recent call last):
>    File "/usr/share/qemu-kvm/dump-guest-memory.py", line 19, in <module>
>      UINTPTR_T = gdb.lookup_type("uintptr_t")
>  gdb.error: No type named uintptr_t.

Oh yeah, I remember that particular error.
Acked-by: Janosch Frank <frankja@linux.vnet.ibm.com>

> 
> This occurs when symbols haven't been loaded first, i.e. neither a
> QEMU binary was loaded nor a QEMU process was attached first. Let's
> better inform the user of how to fix the issue themselves in order
> to avoid more reports.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  scripts/dump-guest-memory.py | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/dump-guest-memory.py b/scripts/dump-guest-memory.py
> index 51acfcd0c053..e56fff6d7e82 100644
> --- a/scripts/dump-guest-memory.py
> +++ b/scripts/dump-guest-memory.py
> @@ -16,7 +16,11 @@ the COPYING file in the top-level directory.
>  import ctypes
>  import struct
> 
> -UINTPTR_T = gdb.lookup_type("uintptr_t")
> +try:
> +    UINTPTR_T = gdb.lookup_type("uintptr_t")
> +except Exception as inst:
> +    raise gdb.GdbError("Symbols must be loaded prior to sourcing dump-guest-memory.\n"
> +                       "Symbols may be loaded by first 'attach'ing a QEMU process id or by 'load'ing a QEMU binary.")>
>  TARGET_PAGE_SIZE = 0x1000
>  TARGET_PAGE_MASK = 0xFFFFFFFFFFFFF000
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [PATCH] dump-guest-memory: more descriptive lookup_type failure

[Laszlo Ersek]

On 03/14/18 15:24, no-reply@patchew.org wrote:

> Checking PATCH 1/1: dump-guest-memory: more descriptive lookup_type failure...
> WARNING: line over 80 characters
> #34: FILE: scripts/dump-guest-memory.py:22:
> +    raise gdb.GdbError("Symbols must be loaded prior to sourcing dump-guest-memory.\n"
> 
> ERROR: line over 90 characters
> #35: FILE: scripts/dump-guest-memory.py:23:
> +                       "Symbols may be loaded by first 'attach'ing a QEMU process id or by 'load'ing a QEMU binary.")
> 
> total: 1 errors, 1 warnings, 12 lines checked

The current "width" of the script is currently:

$ wc -L scripts/dump-guest-memory.py
81 scripts/dump-guest-memory.py

I think it would be good to stick with 80 chars in this patch. (While
adhering to whatever Python idioms are considered necessary -- I think
Janosch and Marc-André can help with that.)

Once that's fixed, please add my:

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

(And, I agree, this error message has been reported several times to me
as well.)

Thanks!
Laszlo