Re: collect some information when qemu-kvm exit

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-06-24 10:24, lidong chen wrote:
> 2011/6/23 Jan Kiszka <jan.kiszka@web.de>:
>> On 2011-06-23 15:56, lidong chen wrote:
>>>>> is it safe to register another signal handler?
>>>>> if somebody know the reason, please tell me.
>>>>>
>>>>> and is it worth to do this?
>>>>
>>> because the core dump file is too big, and the time of core dump is too long.
>>> I do a test, for a guest which have 9.7G memory, the coredump file is
>>> 9.7G, and the time of core dump is 1 minute.
>>>
>>> for the compute node in my system, there are a lot of  cpu and memory
>>> resource, but no disk.
>>>
>>>
>>> total 4.5G
>>> -rw------- 1 root root 9.7G Jun 23 21:31 core-qemu-kvm-24090-1308835893
>>> -rw------- 1 root root 3.9G Jun 23 21:34 core-qemu-kvm-24098-1308835996
>>
>> ulimit -c allows you to restrict the core file size so that it fits on
>> your ram disk. That will at least collect enough information to do a
>> proper post-mortem backtrace in gdb, including register states. It also
>> allows to inspect variables on the stacks and the heap. No need to add a
>> singe line or code to qemu for this.
>>
> 
> if i use 'ulimit -c 6000' to restrict the core file, the backtrace
> can't work correctly.

I've granted a few hundred megs, and it worked for me.

> 
> 26:/corefile # gdb /usr/bin/qemu-kvm core-qemu-kvm-9979-1308888098
> GNU gdb (GDB) SUSE (7.0-0.4.16)
> Copyright (C) 2009 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-suse-linux".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/bin/qemu-kvm...done.
> BFD: Warning: /corefile/core-qemu-kvm-9979-1308888098 is truncated:
> expected core file size >= 10583695360, found: 10051584.
> [New Thread 9981]
> [New Thread 9980]
> Cannot access memory at address 0x7fb26cac1108
> (gdb) backtrace
> Cannot access memory at address 0x7fff489c03b0
> 
> if i use 'ulimit -c unlimited', it work correctly.
> Core was generated by `qemu-kvm -hda
> /var/lib/libvirt/images/sles11-4.img -boot dc -m 9999 -vnc *:0 -k'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x00007f6ba768cb93 in select () from /lib64/libc.so.6
> (gdb) bt
> #0  0x00007f6ba768cb93 in select () from /lib64/libc.so.6
> #1  0x0000000000431b8a in main_loop_wait (timeout=1000)
>     at /usr/src/packages/BUILD_chen/qemu-kvm-0.12.5/vl.c:4006
> #2  0x0000000000455a50 in kvm_main_loop ()
>     at /usr/src/packages/BUILD_chen/qemu-kvm-0.12.5/qemu-kvm.c:2129
> #3  0x00000000004322bc in main_loop () at
> /usr/src/packages/BUILD_chen/qemu-kvm-0.12.5/vl.c:4231
> #4  0x0000000000435fb3 in main (argc=11, argv=0x7fffadc777d8,
> envp=0x7fffadc77838)
>     at /usr/src/packages/BUILD_chen/qemu-kvm-0.12.5/vl.c:6356
> (gdb)
> 
> I google how could gdb handle truncated core files,
> http://sourceware.org/ml/gdb/2008-08/msg00276.html
> 
> there are two potential way to support gdb handle truncated core files:
> 1.modify the code of linux kernel, to support for prioritisation of
> what is dumped.

What we basically need to avoid playing with ulimit is a way to tell the
kernel "do not dump this region", and apply that on the guest memory at
least.

> 2.used coredumper,  http://code.google.com/p/google-coredumper/
> 
> i read the code of function elf_core_dump in linux kernel, it write
> each vma in sequence.

...optionally prioritized by size - or that way. Though we wouldn't need
it given a proper kernel interface. Don't know why such thing does not
exist yet.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux