The QEMU program symbols need to be loaded prior to sourcing the script, i.e. either launch with the program name on the command line or call 'load <program name>' first, or 'attach' to a process id (either from the command line or with 'attach').

While this bug is technically user error, this isn't the first report of this issue, so we should probably improve the error message to avoid future reports. I've written a patch which I'll post upstream now.

I'm not sure what to do with this bug. If we want to protect against user error then I guess we can keep it and target it for 7.6, otherwise we can just close it as not-a-bug.

(In reply to Andrew Jones from comment #2)
> The QEMU program symbols need to be loaded prior to sourcing the script,
> i.e. either launch with the program name on the command line or call 'load
> <program name>' first, or 'attach' to a process id (either from the command
> line or with 'attach').

I was using wrong steps to try to dump memory, after launch gdb with qemu, then it works as expected. 

> 
> While this bug is technically user error, this isn't the first report of
> this issue, so we should probably improve the error message to avoid future
> reports. I've written a patch which I'll post upstream now.

Sorry this was my first time to use dump-guest-memory.py, when this error shows it looks like version incompatible, that's why I report it.

> 
> I'm not sure what to do with this bug. If we want to protect against user
> error then I guess we can keep it and target it for 7.6, otherwise we can
> just close it as not-a-bug.

So this is not a bug. However I prefer to improving the error message like you mentioned above, which can help users to be more clear about this issue.

I'll change the bug title accordingly, however please feel free to close it as 'not-a-bug'. Both solutions are ok for me. 


Thanks,
Pei

Low priority but probably worth fixing. We'll get it in our downstream packages via rebase.

upstream commit 4b17bc933fc26f7a4a306a43597f4d97e3c2dc38 (tag: dump-pull-request, github/dump, dump)
Author: Andrew Jones <drjones>
Date:   Wed Mar 14 16:38:20 2018 +0100

    dump-guest-memory: more descriptive lookup_type failure
    
    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.
    
    Acked-by: Janosch Frank <frankja.ibm.com>
    Signed-off-by: Andrew Jones <drjones>
    Message-Id: <20180314153820.18426-1-drjones>
    Reviewed-by: Fam Zheng <famz>
    Tested-by: Fam Zheng <famz>
    Reviewed-by: Laszlo Ersek <lersek>
    Reviewed-by: Marc-André Lureau <marcandre.lureau>
    Signed-off-by: Marc-André Lureau <marcandre.lureau>

Are we going to rebase qemu to 2.12 in 7.6 ? If not, I am not sure it's worth the backport. Let me know

There is no error.
 
The results are shown below：
gdb
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-110.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(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 22, in <module>
    raise gdb.GdbError("Symbols must be loaded prior to sourcing dump-guest-memory.\n"
gdb.GdbError: Symbols must be loaded prior to sourcing dump-guest-memory.
Symbols may be loaded by 'attach'ing a QEMU process id or by 'load'ing a QEMU binary.
(gdb)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3443