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

Jan Kratochvil
2015-03-05T20:57:52Z

On Thu, 05 Mar 2015 21:52:56 +0100, Sergio Durigan Junior wrote:
> On Thursday, March 05 2015, Jan Kratochvil wrote:
> > On Thu, 05 Mar 2015 04:48:09 +0100, Sergio Durigan Junior wrote:
> >> 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/
>
> No, it doesn't dump. MADV_DONTDUMP activates the "dd" flag in VmFlags,
> and the patch looks for it and, if it finds the flag, it doesn't mark
> the memory mapping to be dumped. However, GDB will create the section
> header in the corefile.

Sorry, I meesed it up even more. For MADV_DONTDUMP you are right, FSF GDB
dumps MADV_DONTDUMP memory, kernel does not and with this patch GDB will not.

What I wanted to say was:

> >> mapping marked as so, and won't try to dump "[vsyscall]" or "[vdso]"

s/won't try/will try/

this one.

> >> 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.
>
> I totally forgot about this, even though we discussed it before. Sorry;
> I am sending a new version of the patch which addresses this issue.

It would be good to get a reply from a kernel aware person what does it mean
before such patch gets accepted. It can be also just a Linux kernel bug.

Jan