[Crash-utility] crash crashes reading qemu dump files

Dave Anderson anderson at redhat.com
Wed Nov 20 14:44:18 UTC 2013



----- Original Message -----
> (2013/11/20 7:19), Andi Kleen wrote:
> >
> > So I wanted to use crash to look at a dump from a qemu KVM guest
> > I write a dump file from the qemu console with
> >
> > dump-guest-core foo
> >
> 
> Hello,
> 
> If you want a crash dump of the running qemu guest machine,
> you can use dump-guest-memory command.
> 
> ETEXI
> 
>      {
>          .name       = "dump-guest-memory",
>          .args_type  = "paging:-p,filename:F,begin:i?,length:i?",
>          .params     = "[-p] filename [begin] [length]",
>          .help       = "dump guest memory to file"
>                        "\n\t\t\t begin(optional): the starting physical
>                        address"
>                        "\n\t\t\t length(optional): the memory size, in
>                        bytes",
>          .mhandler.cmd = hmp_dump_guest_memory,
>      },
> 
> 
> STEXI
> @item dump-guest-memory [-p] @var{protocol} @var{begin} @var{length}
> @findex dump-guest-memory
> Dump guest memory to @var{protocol}. The file can be processed with crash or gdb.
>    filename: dump file name
>      paging: do paging to get guest's memory mapping
>       begin: the starting physical address. It's optional, and should be
>              specified with length together.
>      length: the memory size, in bytes. It's optional, and should be
>      specified
>              with begin together.
> 
> BTW, I heard the dump-guest-core command for the first time.
> According to the source code, it looks like the command to decide whether
> or not to include VM guest in a process core dump generated by KVM
> host kernel.
> 
> static void qemu_ram_setup_dump(void *addr, ram_addr_t size)
> {
>      int ret;
> 
>      /* Use MADV_DONTDUMP, if user doesn't want the guest memory in the core
>      */
>      if (!qemu_opt_get_bool(qemu_get_machine_opts(),
>                             "dump-guest-core", true)) {
>          ret = qemu_madvise(addr, size, QEMU_MADV_DONTDUMP);
>          if (ret) {
>              perror("qemu_madvise");
>              fprintf(stderr, "madvise doesn't support MADV_DONTDUMP, "
>                              "but dump_guest_core=off specified\n");
>          }
>      }
> }
> 
> According to qemu-ptions.hx, syntax of the command is:
> 
> @item dump-guest-core=on|off
> Include guest memory in a core dump. The default is on.
> 
> So, it seems strange to me that the fact "foo" file was generated...
> 
> --
> Thanks.
> HATAYAMA, Daisuke

I'd never heard of "dump-guest-core", but apparently the file type is
initially being accepted as a kdump ELF vmcore.   But then later it
craps out in the embedded gdb code when crash is checking whether 
the vmlinux file contains debuginfo data for the struct task_struct.
It should just fail, return back, and fail the session with a message
indicating that there is no debuginfo data, like this:

 $ strip vmlinux
 $ crash vmlinux

 crash 7.0.3
 Copyright (C) 2002-2013  Red Hat, Inc.
 Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
 Copyright (C) 1999-2006  Hewlett-Packard Co
 Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
 Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
 Copyright (C) 2005, 2011  NEC Corporation
 Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
 Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
 This program is free software, covered by the GNU General Public License,
 and you are welcome to change it and/or distribute copies of it under
 certain conditions.  Enter "help copying" to see the conditions.
 This program has absolutely no warranty.  Enter "help warranty" for details.
 
 crash: vmlinux: no .gnu_debuglink section 

 crash: vmlinux: no debugging data available

 $

But from the backtrace I can't tell what's happening down in the bowels of gdb.

Anyway, I've only used "virsh dump --memory-only", which apparently is a wrapper
around "dump-guest-memory" which does not use the -p argument, which is preferable
for the crash utility.  

Dave





More information about the Crash-utility mailing list