2011/6/24 Jan Kiszka <jan.kiszka@xxxxxxxxxxx>: > On 2011-06-24 10:55, Jan Kiszka wrote: >> 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) > > And I've gdb 7.2.50.20101006-cvs here. Maybe that also contributes to a > working setup. > i try newer version of gdb, it still can't work correctly. 26:/corefile # /usr/local/bin/gdb /usr/bin/qemu-kvm core-qemu-kvm-20458-1308912006 GNU gdb (GDB) 7.2.90.20110530-cvs Copyright (C) 2011 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-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/qemu-kvm...done. [New LWP 20458] [New LWP 20459] Cannot access memory at address 0x7fbffdca3108 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 0x00007fbffb1ccb93 in ?? () (gdb) bt #0 0x00007fbffb1ccb93 in ?? () Cannot access memory at address 0x7ffffc6daaf0 to tell kernel didn't dump guest os memory, i set coredump_filter to 0x32, cancel the dump of anonymous private mappings. the coredump_filter is 0x33 default, echo 0x32 > /proc/14528/coredump_filter and the size of core file is only 224K. -rw------- 1 root root 224K Jun 24 20:46 core-qemu-kvm-14528-1308919614 but the gdb can't not work correctly. GNU gdb (GDB) 7.2.90.20110530-cvs Copyright (C) 2011 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-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/qemu-kvm...done. [New LWP 14528] [New LWP 14529] [New LWP 14537] 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 0x00007f8988221b93 in ?? () (gdb) bt #0 0x00007f8988221b93 in ?? () Cannot access memory at address 0x7fffec55dee0 (gdb) i guess the address 0x00007f8988221b93 is in select from /lib64/libc.so.6. > 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
