Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902)

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Thu, 05 Mar 2015 04:48:09 +0100, Sergio Durigan Junior wrote:
>   bit 0  Dump anonymous private mappings.
>   bit 1  Dump anonymous shared mappings.
>   bit 2  Dump file-backed private mappings.
>   bit 3  Dump file-backed shared mappings.
>   bit 4 (since Linux 2.6.24)
>          Dump ELF headers.
>   bit 5 (since Linux 2.6.28)
>          Dump private huge pages.
>   bit 6 (since Linux 2.6.28)
>          Dump shared huge pages.
[...]
> The default value for this file, used by the Linux kernel, is 0x33,
> which means that bits 0, 1 and 4 are enabled.  This is also the default

and 5

> for GDB implemented in this patch, FWIW.
[...]
> With Oleg's help, we could improve the current algorithm for determining
> whether a memory mapping is anonymous/file-backed, private/shared.  GDB
> now also respects the MADV_DONTDUMP flag and does not dump the memory

s/does not dump/does dump/

> mapping marked as so, and won't try to dump "[vsyscall]" or "[vdso]"
> mappings as before (just like the Linux kernel).

Currently it also tries to dump [vvar] (by default rules) but that is
unreadable for some reason, causing:
warning: Memory read failed for corefile section, 8192 bytes at 0x7ffff6ceb000.
                                                                ^^^^^^^^^^^^^^
Saved corefile /tmp/1j
(gdb) _
# grep 7ffff6ceb000 /proc/$p/maps
7ffff6ceb000-7ffff6ced000 r--p 00000000 00:00 0                          [vvar]
^^^^^^^^^^^^                                                              ^^^^

I do not know what [vvar] is good for and why it cannot be read.


>   It is worth mentioning that, from all those checks described above,
>   the most fragile is the one to see if the file name ends with "
>   (deleted)".  This does not necessarily mean that the mapping is
>   anonymous, because the deleted file associated with the mapping may
>   have been a hard link to another file, for example.  The Linux kernel
>   checks to see if "i_nlink == 0", but GDB cannot easily do this check.

# stat /proc/21604/map_files/400000-4ec000 
  File: ‘/proc/21604/map_files/400000-4ec000’ -> ‘/tmp/bash-deleted’
  Size: 64        	Blocks: 0          IO Block: 1024   symbolic link
Device: 3h/3d	Inode: 1554082     Links: 1
# stat -L /proc/21604/map_files/400000-4ec000 
  File: ‘/proc/21604/map_files/400000-4ec000’
  Size: 1051464   	Blocks: 2056       IO Block: 4096   regular file
Device: fd01h/64769d	Inode: 5509691     Links: 1
# rm /tmp/bash-deleted
# stat -L /proc/21604/map_files/400000-4ec000 
  File: ‘/proc/21604/map_files/400000-4ec000’
  Size: 1051464   	Blocks: 2056       IO Block: 4096   regular file
Device: fd01h/64769d	Inode: 5509691     Links: 0
                                                  ^

One could find if i_nlink == 0 if it would be enough.  But it would work only
if GDB runs as root so it is probably not worth coding it:

$ ls -ld /proc/3803/map_files
dr-x------ 2 lace lace 0 Mar  5 16:44 /proc/3803/map_files/
$ stat /proc/3803/map_files/400000-4ec000
stat: cannot stat ‘/proc/3803/map_files/400000-4ec000’: Operation not permitted


Jan