Hi Kawai:
I find that if set coredump_filter to 0x32, the core file can't gdb
work correctly.
because the value of anon_vma for stack or brk vma is also not NULL.
in function vma_dump_size, stack and brk vma will not dump if
FILTER(ANON_PRIVATE) is 0.
if ( vma->anon_vma && FILTER(ANON_PRIVATE) ) {
goto whole;
}
are there any method only didn't dump anonymous private vma caused by mmap?
the purpose i do this is to support qemu-kvm didn't dump guest os
memory, which is anonymous private memory caused by mmap system call.
i find another way to implement this function, but i think is not the best way.
because the guest os memory also have VM_MERGEABLE flag, so i can add
a option in
coredump_filter and only didn't dump guest os memory.
/* 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;
thanks.
2011/7/2 lidong chen <chen.lidong.kernel@xxxxxxxxx>:
> 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
