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. 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. 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. > Jan > > -- 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
