You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've discovered that on some systems (newer kernels especially), core dump writing is failing with EFAULT while trying to read some of the process memory. Investigation shows that the memory segment in question is the "vvar" segment which contains directly-mapped kernel variables used with VDSO. In older systems that segment either didn't appear in the maps / smaps file at all, or else trying to read it succeeded. But in newer systems I'm seeing the first 4k read (vvar is always 8k AFAICT) succeed, but the second 4k read fails with EFAULT.
Reading various mailing lists etc. it seems like this memory segment isn't needed for a core file anyway, so I just skipped it.
My repository https://github.com/madscientist/google-coredumper is based on the version from AmadeusItGroup https://github.com/AmadeusITGroup/CoreDumper (has enhancements for RELRO support), plus a few fixes from other people and some of my own. My current master HEAD incorporates all the fixes I've found in various GitHub forks (but doesn't pull in support for "corepoint" from AmadeusItGroup).
The RELRO support changes the coredumper library to parse the proc smaps file instead of proc maps, so my fix involves reading the VmFlags value from smaps and omitting any memory segment which has the "dd" (VM_DONTDUMP) flag set.
If you wanted to keep this version, that reads the maps file instead, you'll need to check the type of the segment and omit it if the type is "[vvar]" (or something like that).
The text was updated successfully, but these errors were encountered:
I've discovered that on some systems (newer kernels especially), core dump writing is failing with EFAULT while trying to read some of the process memory. Investigation shows that the memory segment in question is the "vvar" segment which contains directly-mapped kernel variables used with VDSO. In older systems that segment either didn't appear in the maps / smaps file at all, or else trying to read it succeeded. But in newer systems I'm seeing the first 4k read (vvar is always 8k AFAICT) succeed, but the second 4k read fails with EFAULT.
Reading various mailing lists etc. it seems like this memory segment isn't needed for a core file anyway, so I just skipped it.
My repository https://github.com/madscientist/google-coredumper is based on the version from AmadeusItGroup https://github.com/AmadeusITGroup/CoreDumper (has enhancements for RELRO support), plus a few fixes from other people and some of my own. My current master HEAD incorporates all the fixes I've found in various GitHub forks (but doesn't pull in support for "corepoint" from AmadeusItGroup).
The RELRO support changes the coredumper library to parse the proc smaps file instead of proc maps, so my fix involves reading the VmFlags value from smaps and omitting any memory segment which has the "dd" (VM_DONTDUMP) flag set.
If you wanted to keep this version, that reads the maps file instead, you'll need to check the type of the segment and omit it if the type is "[vvar]" (or something like that).
The text was updated successfully, but these errors were encountered: