This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902)
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: GDB Patches <gdb-patches at sourceware dot org>, Pedro Alves <palves at redhat dot com>, Oleg Nesterov <oleg at redhat dot com>
- Date: Thu, 5 Mar 2015 16:48:27 +0100
- Subject: Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902)
- Authentication-results: sourceware.org; auth=none
- References: <878ufc9kau dot fsf at redhat dot 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