On 2011-06-24 10:24, lidong chen wrote: > 2011/6/23 Jan Kiszka <jan.kiszka@xxxxxx>: >> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
