3party/crashpad
0
0
Fork 0
mirror of https://github.com/chromium/crashpad.git synced 2024-12-27 07:14:10 +08:00
Code Issues Projects Releases Wiki Activity

mac: Update cl_kernels workaround for macOS 10.13 (and later)

Browse Source 
Since Apple closed https://openradar.appspot.com/20239912 without fixing
anything, it looks like we’ll be stuck with these quriky cl_kernels
modules for quite some time. Allow these modules to be tolerated on any
OS version >= 10.10, where they first appeared in a broken state, by
removing the upper bound for the OS version to tolerate with this quirk.

The tolerance was previously expanded to include 10.11 in
cd1f8fa3d2f2c76802952beac71ad85f51bbf771 and 10.12 in
6fe7c5414e46acfa30e8984513bf0896e91b9407. After this third update, this
should hopefully no longer be an annual exercise.

Bug: crashpad:185, crashpad:186
Change-Id: I66d409f2d1638bcf7601b6622f000be245230f34
Reviewed-on: https://chromium-review.googlesource.com/534253
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This commit is contained in:
Mark Mentovai 2017-06-13 14:55:17 -04:00 committed by Commit Bot
parent f845797732
commit 2851e5cfc8
1 changed files with 23 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
snapshot/mac/mach_o_image_segment_reader.cc
View File

@ -120,36 +120,29 @@ bool MachOImageSegmentReader::Initialize(ProcessReader* process_reader,
sections_.size(),
load_command_info.c_str());
if (section_segment_name != segment_name) {
// cl_kernels modules (for OpenCL) aren’t ld output, and they’re formatted
// incorrectly on OS X 10.10 and later. They have a single __TEXT segment,
// but one of the sections within it claims to belong to the __LD segment.
// This mismatch shouldn’t happen. This errant section also has the
// S_ATTR_DEBUG flag set, which shouldn’t happen unless all of the other
// sections in the segment also have this bit set (they don’t). These odd
// sections are reminiscent of unwind information stored in MH_OBJECT
// images, although cl_kernels images claim to be MH_BUNDLE. Because at
// least one cl_kernels module will commonly be found in a process, and
// sometimes more will be, tolerate this quirk.
//
// https://openradar.appspot.com/20239912
bool ok = false;
if (file_type == MH_BUNDLE && module_name == "cl_kernels") {
int mac_os_x_minor_version = MacOSXMinorVersion();
if ((mac_os_x_minor_version >= 10 && mac_os_x_minor_version <= 12) &&
segment_name == SEG_TEXT &&
section_segment_name == "__LD" &&
section_name == "__compact_unwind" &&
(section.flags & S_ATTR_DEBUG)) {
ok = true;
}
}
if (!ok) {
LOG(WARNING) << "section.segname incorrect in segment " << segment_name
<< section_info;
return false;
}
// cl_kernels modules (for OpenCL) aren’t ld output, and they’re formatted
// incorrectly on OS X 10.10 and later. They have a single __TEXT segment,
// but one of the sections within it claims to belong to the __LD segment.
// This mismatch shouldn’t happen. This errant section also has the
// S_ATTR_DEBUG flag set, which shouldn’t happen unless all of the other
// sections in the segment also have this bit set (they don’t). These odd
// sections are reminiscent of unwind information stored in MH_OBJECT
// images, although cl_kernels images claim to be MH_BUNDLE. Because at
// least one cl_kernels module will commonly be found in a process, and
// sometimes more will be, tolerate this quirk.
//
// https://openradar.appspot.com/20239912
if (section_segment_name != segment_name &&
!(file_type == MH_BUNDLE &&
module_name == "cl_kernels" &&
MacOSXMinorVersion() >= 10 &&
segment_name == SEG_TEXT &&
section_segment_name == "__LD" &&
section_name == "__compact_unwind" &&
(section.flags & S_ATTR_DEBUG))) {
LOG(WARNING) << "section.segname incorrect in segment " << segment_name
<< section_info;
return false;
}
CheckedMachAddressRange section_range(