Core dumps get broken due to too many memory maps

Issue

• In a certain situation, such as multi-thread programs with too many threads, broken core dumps are generated, in which GDB and binary utilities cannot see memory correctly.

• Here is the example showing how gdb cannot handle the corrupted coredump.

     $ gdb ./mkmmaps core.8998 
      GNU gdb (GDB) Fedora (6.8.50.20090811-2.el6)
      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-redhat-linux-gnu".
      For bug reporting instructions, please see:
      <http://www.gnu.org/software/gdb/bugs/>...
      Cannot access memory at address 0x7fa31afec0c8
      (gdb) bt
      Cannot access memory at address 0x7fffc6770da8
  

• Specifically, the reason is in the e_phnum field size of ELF header. The e_phnum represents the number of program headers and mostly corresponds to the number of memory maps. The problem is that if memory maps are larger than e_phnum can represent then e_phnum overflows. (In the above example, each stack of the thread is mapped onto a memory map; so in multi-thread programs, there are at least as many memory maps as stacks.)

• Since this issue is in ELF specification, it is necessary to extend  the ELF specification and then to have kernel, gdb and binutils   conform to the extension respectively.

• The explanation for ELF extension is available in
    @URL: http://lkml.org/lkml/2010/1/3/103
    @GIT: commit 05f47fda9fc5b17bfab189e9d54228025befc996