I think there are no way to tell the kernel didn't dump guest os memory.
for current kernel, /proc/<pid>/coredump_filter only support the
following 7 memory types.
- (bit 0) anonymous private memory
- (bit 1) anonymous shared memory
- (bit 2) file-backed private memory
- (bit 3) file-backed shared memory
- (bit 4) ELF header pages in file-backed private memory areas (it
is effective only if the bit 2 is cleared)
- (bit 5) hugetlb private memory
- (bit 6) hugetlb shared memory
but for a process, there are also other anonymous private memory vma.
i modify the funcation vma_dump_size like this, only didn't dump guest
memory. then gdb can work correctly and the core file is 22M.
maybe we need add a option for coredump_filter.
--- /usr/src/linux/fs/binfmt_elf.c 2011-05-10 08:02:45.000000000 -0400
+++ fs/binfmt_elf.c 2011-07-02 06:30:17.000000000 -0400
@@ -1154,8 +1154,11 @@
}
/* Dump segments that have been written to. */
- if (vma->anon_vma && FILTER(ANON_PRIVATE))
+ if (vma->anon_vma && !(vma->vm_flags & VM_MERGEABLE) ) {
goto whole;
+ } else if ( vma->anon_vma && FILTER(ANON_PRIVATE) ) {
+ goto whole;
+ }
if (vma->vm_file == NULL)
return 0;
linux-gzvm:/opt/c00104598/coretest # gdb main core
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 /opt/c00104598/coretest/main...done.
warning: core file may not match specified executable file.
[New Thread 9099]
Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
Try: zypper install -C
"debuginfo(build-id)=17c088070352d83e7afc43d83756b00899fd37f0"
Core was generated by `/usr/bin/qemu-kvm -S -M pc-0.12 -enable-kvm -m
512 -nodefaults -boot c -hda /op'.
Program terminated with signal 11, Segmentation fault.
#0 0x000000000049a577 in ?? ()
(gdb) bt
#0 0x000000000049a577 in ?? ()
#1 0x00000000004d2385 in ?? ()
#2 0x0000000000f18960 in ?? ()
#3 0x0000000000f18960 in ?? ()
#4 0x00007fffa2a5ff40 in ?? ()
#5 0x00007fffa2a5ffc0 in ?? ()
#6 0x0000000000f18960 in ?? ()
#7 0x0000000000000014 in ?? ()
#8 0x00007fffa2a5ff40 in ?? ()
#9 0x00007fffa2a5ffc0 in ?? ()
#10 0x00007fffa2a60040 in ?? ()
#11 0x00000000004d46b1 in ?? ()
#12 0x00007fffa2a5ffc0 in ?? ()
#13 0x0000000000cb1d80 in ?? ()
#14 0x0000000000000001 in ?? ()
#15 0x000000000040c752 in ?? ()
#16 0x00007fac8c4e4128 in _r_debug ()
#17 0x000003e88c2cd933 in ?? ()
#18 0x0000000000000000 in ?? ()
(gdb)
2011/6/24 lidong chen <chen.lidong.kernel@xxxxxxxxx>:
> 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
