Adjust breakpad module size to match adjusted start_addr.

client/linux/minidump_writer/linux_dumper.cc

Index: client/linux/minidump_writer/linux_dumper.cc
diff --git a/client/linux/minidump_writer/linux_dumper.cc b/client/linux/minidump_writer/linux_dumper.cc
index 00d18189d6683030153b0b231f8eaa8597738ef4..43b74ad9de7e4e536e4622aaa21d24705af5a9e0 100644
--- a/client/linux/minidump_writer/linux_dumper.cc
+++ b/client/linux/minidump_writer/linux_dumper.cc
@@ -510,10 +510,15 @@ void LinuxDumper::LatePostprocessMappings() {
     }
     if (ehdr.e_type == ET_DYN) {
       // Compute the effective load bias for this mapped library, and update
-      // the mapping to hold that rather than |start_addr|. Where the library
-      // does not contain Android packed relocations, GetEffectiveLoadBias()
-      // returns |start_addr| and the mapping entry is not changed.
-      mapping->start_addr = GetEffectiveLoadBias(&ehdr, mapping->start_addr);
+      // the mapping to hold that rather than |start_addr|, at the same time
+      // adjusting |size| to account for the change in |start_addr|. Where
+      // the library does not contain Android packed relocations,
+      // GetEffectiveLoadBias() returns |start_addr| and the mapping entry
+      // is not changed.
+      const uintptr_t load_bias = GetEffectiveLoadBias(&ehdr,
+                                                       mapping->start_addr);
+      mapping->size += mapping->start_addr - load_bias;

[Primiano Tucci (use gerrit), 2015/06/25 14:44:01]

can load_bias ever be > start_addr (maybe by mistakenly parsing the elf header)?
Should you have a check in that case?

[simonb (inactive), 2015/06/25 15:14:35]

From coding errors in the proc/$$/maps or ELF data parsers?  A check here
wouldn't protect.  If start_addr is wrong from misparsing, substituting an
incorrect value for a different incorrect value won't make the result any more
correct.

If load_bias is genuinely > start_addr due to underflow from start_addr being in
very low memory -- beneath 6mb or so say, and a case we hope is pathological --
the symmetrical overflow in this expression means that size still comes out
correctly.  Demo:

#include <iostream>
#include <inttypes.h>
int main() {
  uint32_t start_addr = 0x1000;
  uint32_t size       = 0x200000;
  std::cout << std::hex << "Before: start_addr = " << start_addr
            << ", size = " << size << std::dec << std::endl;
  const uint32_t hole_size  = 0x30000;
  const uint32_t load_bias = start_addr - hole_size;
  // Model a load bias adjustment that wraps start_addr.
  if (load_bias > start_addr)
    std::cout << "Note  : start_addr > load_bias!" << std::endl;
  size += start_addr - load_bias;
  start_addr = load_bias;
  std::cout << std::hex << "After : start_addr = " << start_addr
            << ", size = " << size << std::dec << std::endl;
}

Before: start_addr = 1000, size = 200000
Note  : start_addr > load_bias!
After : start_addr = fffd1000, size = 230000

The case where load_bias can be genuinely > start_addr is a separate breakpad
issue.

+      mapping->start_addr = load_bias;
     }
   }
 }