mirror of https://github.com/chromium/crashpad.git synced 2025-03-09 14:06:33 +00:00

Go to file

Joshua Peraza 52ff1accbb linux: Fix locating modules with multiple mappings from offset 0

The general strategy used by Crashpad to determine loaded modules is to
read the link_map to get the addresses of the dynamic arrays for all
loaded modules. Those addresses can then be used to query the MemoryMap
to locate the module's mappings, and in particular the base mapping
from which Crashpad can parse the entire loaded ELF file.

ELF modules are typically loaded in several mappings with varying
permissions for different segments. The previous strategy used to find
the base mapping for a module was to search backwards from the mapping
for the dynamic array until a mapping from file offset 0 was found for
the same file. This fails when the file is mapped multiple times from
file offset 0, which can happen if the first page of the file contains
a GNU_RELRO segment.

This new strategy queries the MemoryMap for ALL mappings associated
with the dynamic array's mapping, mapped from offset 0. The consumer
(process_reader_linux.cc) can then determine which mapping is the
correct base by attempting to parse a module at that address and
corroborating the PT_DYNAMIC or program header table address from the
parsed module with the values Crashpad gets from the link_map or
auxiliary vector.

Bug: crashpad:30
Change-Id: Ibfcbba512e8fccc8c65afef734ea5640b71e9f70
Reviewed-on: https://chromium-review.googlesource.com/1139396
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>

2018-07-26 15:33:15 +00:00

build

Make BuildHandlerArgvStrings() return its result

2018-07-20 20:31:14 +00:00

client

linux: Fix broken tests with address sanitizer

2018-07-24 19:52:58 +00:00

compat

linux, non-glibc: fix build after eb7d8a4c

2018-07-10 21:27:15 +00:00

doc

Doc update for GN build