5 Commits

Author SHA1 Message Date
Mark Mentovai
107fb76317 mac: Handle _dyld_get_all_image_infos() not being available on 10.13
_dyld_get_all_image_infos() was only used in test code in Crashpad.

This addresses two related problems.

When running on 10.13 or later, _dyld_get_all_image_infos() is not
available. It appears to still be implemented in dyld, but its symbol is
now private. This was always known to be an “internal” interface. When
it’s not available, fall back to obtaining the address of the process’
dyld_all_image_infos structure by calling task_info(…, TASK_DYLD_INFO,
…). Note that this is the same thing that the code being tested does,
although the tests are not rendered entirely pointless because the code
being tested consumes dyld_all_image_infos through its own
implementation of an out-of-process reader interface, while the
dyld_all_image_infos data obtained by _dyld_get_all_image_infos() is
handled strictly in-process by ordinary memory reads. This is covered by
bug 187.

When building with the 10.13 SDK, no _dyld_get_all_image_infos symbol is
available to link against. In this case, access the symbol strictly at
runtime via dlopen() if it may be available, or when expecting to only
run on 10.13 and later, don’t even bother looking for this symbol. This
is covered by part of bug 188.

Bug: crashpad:185, crashpad:187, crashpad:188
Change-Id: Ib283e070faf5d1ec35deee420213b53ec24fb1d3
Reviewed-on: https://chromium-review.googlesource.com/534633
Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-06-14 15:08:05 +00:00
Mark Mentovai
c281e30f93 mac: Update the dyld_all_image_infos structure for 10.12
BUG=crashpad:120

Change-Id: I7b2df5f2de13517b2586569ce267bcb0ae845101
Reviewed-on: https://chromium-review.googlesource.com/353830
Reviewed-by: Robert Sesek <rsesek@chromium.org>
2016-06-20 16:14:24 +00:00
Mark Mentovai
9086d25ce8 Don’t trigger EXC_CORPSE_NOTIFY on OS X 10.11
CrashReportExceptionHandler::CatchMachException() must always set a
valid new_state. Failing to do so appears to trigger corpse generation
on OS X 10.11. This is addressed by calling ExcServerCopyState().
Previously, this was not done for exceptions forwarded to the user
ReportCrash, under the apparent mistaken assumption that ReportCrash
would do it. However, ReportCrash is given copies of out-parameters like
new_state to explicitly prevent it from influencing Crashpad’s returned
state.

ExcServerSuccessfulReturnValue() must not return MACH_RCV_PORT_DIED for
an EXC_CRASH handler on OS X 10.11. This appears to trigger corpse
generation. This is addressed by always returning KERN_SUCCESS from
EXC_CRASH handlers on OS X 10.11.

This also adds generic EXC_CORPSE_NOTIFY support throughout Crashpad.
The crashpad_handler does not listen for this exception type, but it is
now possible to work with this exception type using tools like
exception_port_tool and catch_exception_tool.

BUG=crashpad:48
TEST=Crashes handled by crashpad_handler do not result in the generation
     of reports in the root /Library/Logs/DiagnosticReports.

R=kerrnel@chromium.org, rsesek@chromium.org

Review URL: https://codereview.chromium.org/1305893010 .
2015-09-04 14:29:12 -04:00
Mark Mentovai
850ec0657d Drop 10.5 support.
TEST=util_test
R=rsesek@chromium.org

Review URL: https://codereview.chromium.org/575823002
2014-09-16 11:55:55 -04:00
Mark Mentovai
dfe81014f7 Add compat to Crashpad.
compat includes headers providing definitions normally provided by the
system, in cases where the system SDK does not always provide the
correct or up-to-date definitions, and cases where code on different
platforms needs to access definitions normally only available on one
platform.

To provide definitions on a single platform, where the system SDK may
not provide the definitions correctly, use subdirectories named for the
platform, such as “mac”.

To provide definitions normally available on only one platform to
others, use subdirectories that identify that they are to be used on
platforms other than the one that originated their definitions, such as
“non_win”.

In all cases, headers should be named as they are natively in their
respective SDKs, so that it’s possible to #include them according to
their usual names.

R=rsesek@chromium.org

Review URL: https://codereview.chromium.org/432843002
2014-07-31 13:45:51 -04:00