4:19 p.m.
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
Then I do on the host
crash vmlinux foo
...
<segmentation violation in gdb>
In gdb I see it seems to jump to 0
(gdb) p $pc
$1 = (void (*)()) 0x0
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x000000000073707a in ui_file_write (length_buf=1,
buf=0x7fffffffbaaf "N", file=<optimized out>) at ui-file.c:224
#2 tee_file_write (file=<optimized out>, buf=0x7fffffffbaaf "N",
length_buf=1) at ui-file.c:758
#3 0x00000000007337d6 in fputc_unfiltered (stream=0x126de20,
c=<optimized out>) at utils.c:2209
#4 fputs_maybe_filtered (linebuffer=linebuffer@entry=0x1534a00 "No
symbol \"task_struct\" in current context.\n",
stream=stream@entry=0x126de20, filter=1) at utils.c:2126
#5 0x00000000007339b0 in vfprintf_maybe_filtered (stream=0x126de20,
format=format@entry=0x9db4b5 "%s\n",
args=args@entry=0x7fffffffbaf8, filter=1, filter=1) at utils.c:2332
#6 0x0000000000734a4c in vfprintf_filtered (args=0x7fffffffbaf8,
format=0x9db4b5 "%s\n", stream=<optimized out>) at utils.c:2340
#7 fprintf_filtered (stream=<optimized out>,
format=format@entry=0x9db4b5 "%s\n") at utils.c:2392
#8 0x0000000000676f67 in throw_exception (exception=...) at
exceptions.c:234
#9 0x0000000000677219 in throw_it (reason=reason@entry=RETURN_ERROR,
error=error@entry=GENERIC_ERROR, fmt=<optimized out>,
ap=ap@entry=0x7fffffffbc48) at exceptions.c:434
#10 0x0000000000677436 in throw_verror (error=error@entry=GENERIC_ERROR,
fmt=<optimized out>, ap=ap@entry=0x7fffffffbc48)
at exceptions.c:440
#11 0x00000000007323d4 in error (string=<optimized out>) at utils.c:717
#12 0x00000000005ea1a3 in c_parse_internal () at c-exp.y:862
#13 0x00000000005ea4f9 in c_parse () at c-exp.y:3064
#14 0x00000000006a2fe1 in parse_exp_in_context
(stringptr=stringptr@entry=0x7fffffffda18, pc=pc@entry=0,
block=block@entry=0x0,
comma=comma@entry=0, out_subexp=out_subexp@entry=0x0,
void_context_p=0) at parse.c:1234
#15 0x00000000006a31e5 in parse_exp_1
(stringptr=stringptr@entry=0x7fffffffda68, pc=pc@entry=0,
block=block@entry=0x0,
comma=comma@entry=0) at parse.c:1136
#16 0x00000000006a3239 in parse_expression (string=0x8739b0
"task_struct") at parse.c:1279
#17 0x000000000064b270 in gdb_get_datatype (req=0xe61620 <shared_bufs>)
at symtab.c:5330
#18 gdb_command_funnel (req=req@entry=0xe61620 <shared_bufs>) at
symtab.c:5208
#19 0x00000000004ddc45 in gdb_interface (req=req@entry=0xe61620
<shared_bufs>) at gdb_interface.c:397
#20 0x00000000004de102 in gdb_session_init () at gdb_interface.c:244
#21 0x0000000000466c14 in main_loop () at main.c:637
#22 0x0000000000678e83 in captured_command_loop (data=data@entry=0x0) at
main.c:258
#23 0x000000000067772a in catch_errors (func=func@entry=0x678e70
<captured_command_loop>, func_args=func_args@entry=0x0,
errstring=errstring@entry=0x8b201f "", mask=mask@entry=6) at
exceptions.c:557
#24 0x0000000000679e16 in captured_main (data=data@entry=0x7fffffffde00)
at main.c:1064
#25 0x000000000067772a in catch_errors (func=func@entry=0x679150
<captured_main>, func_args=func_args@entry=0x7fffffffde00,
errstring=errstring@entry=0x8b201f "", mask=mask@entry=6) at
exceptions.c:557
#26 0x000000000067a177 in gdb_main (args=0x7fffffffde00) at main.c:1079
#27 gdb_main_entry (argc=<optimized out>,
argv=argv@entry=0x7fffffffdf58) at main.c:1099
#28 0x00000000004dce84 in gdb_main_loop (argc=<optimized out>,
argc@entry=3, argv=argv@entry=0x7fffffffdf58) at gdb_interface.c:76
#29 0x000000000046549f in main (argc=3, argv=0x7fffffffdf58) at
main.c:613
Environment:
Linux 3.11, current mainline linux (same result)
FC19, qemu-system-x86-1.4.2-12.fc19.x86_64
Known problem?
-Andi
--
ak(a)linux.intel.com -- Speaking for myself only
7:12 p.m.
(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
8:44 a.m.
----- 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
3876
days inactive
3877
days old
devel@lists.crash-utility.osci.io
2 comments
3 participants
participants (3)
-
Andi Kleen -
Dave Anderson -
HATAYAMA Daisuke