If building for chromium, honor the ios_is_app_extension gn variable
that is set per toolchain. When it is defined, the code is built for
an application extension (i.e. -fapplication-extension is passed to
the compiler).
Use CRASHPAD_IS_IOS_APP_EXTENSION build guard to not compile code
that use unavailable extension when ios_is_app_extension is set. If
the variable is not set, then check at runtime whether the API can
be used or not (if the crashpad client uses the same toolchain for
the main application and its application extensions).
This is required to pass -fapplication-extension to the compiler when
building application extensions (which allow catching API that is not
available to application extensions).
Bug: 40120082
Change-Id: I28d545fcfd0f8662430c40ff202b79b0c2b2ff8b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5286216
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Sylvain Defresne <sdefresne@chromium.org>
This reverts commit ca6d64d0ae4905ad7033adab0a28273a0741ee5c.
Reason for revert: The changes did not actually fix the problem once combined with the latest changes from mini_chromium.
Original change's description:
> [fuchsia][mac] Fix build errors
>
> A recent CL [1] broke Fuchsia's Crashpad roller due to duplicate build
> argument declarations. This CL ensures that sysroot.gni is only imported once.
>
> [1] https://chromium-review.googlesource.com/c/chromium/mini_chromium/+/4651973
>
> Fixed: fuchsia:131454
> Change-Id: Idcf6ac65cdffee2c9a9551559a8aab0063044428
> Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4743381
> Reviewed-by: Joshua Peraza <jperaza@chromium.org>
> Commit-Queue: Thomas Gales <tgales@google.com>
Change-Id: Id3dc42484fbd87e242756c8d2889d2e404370ac7
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4753637
Commit-Queue: Thomas Gales <tgales@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
CaptureContext isn't actually used on Fuchsia and there is a desire to
remove `ucontext_t` from Fuchsia as it isn't a real concept on Fuchsia
and was only added as a placeholder. Moreover, `ucontext_t` won't ever
be added to Fuchsia for RISC-V.
Bug: fuchsia:123052
Fixed: fuchsia:131112
Fixed: fuchsia:127655
Tested: `fx test crashpad` on core.x64 emulator
Tested: `fx test crashpad` on ARM64 device
Tested: `fx shell crasher` @ 16b19a9891978487 on ARM64 device, ran
through Breakpad stackwalker locally as well
Tested: `fx build crashpad_tests` for minimal.riscv64
Change-Id: I4695054426df78a9deff8c9ea9c478b5bf9701b1
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4717085
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Thomas Gales <tgales@google.com>
Pointer Authentication works by adding a signature to the top bits of
an instruction or data pointer (only instruction pointers on the stack
are currently signed in Chromium). This can confuse range checks,
because they need to strip the top bits. Masking these bits during sanitization range checks prevents confusion.
Test: Testing was done manually on a device with pointer authentication enabled.
Bug: crashpad:364
Bug: 919548
Change-Id: I2e739cadb2844cfaf73a75596d664135aeb5faac
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4387271
Commit-Queue: Adam Walls <avvall@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Ben Hamilton <benhamilton@google.com>
This CL introduces a new class ScopedVMMap, a fork of ScopedVMRead
which maps the memory using vm_remap() instead of reading it.
This is useful for Annotations which use ScopedSpinGuard to
protect reads from simultaneous writes; the in-process intermediate
dump handler can try to take the spin guard when reading such
an Annotation and skip reading it if it the spin guard could not
be obtained.
Change-Id: I60d7a48d1ba4e5d2dfdb44307b78b4d9ffb73560
Bug: crashpad:437
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4114550
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Ben Hamilton <benhamilton@google.com>
... as we move crashpad from //third_party/crashpad to
//third_party/crashpad/src
Change-Id: I081520ad44334cc83397234e5d16535d0db4806d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4132465
Reviewed-by: Francois Rousseau <frousseau@google.com>
Commit-Queue: Jay Zhuang <jayzhuang@google.com>
To support a new crashpad::RingBufferAnnotation type which can be safely
written to and read from simultaneously by different threads/processes,
this CL introduces a new class ScopedSpinGuard, which is a simple RAII
wrapper around an atomic boolean.
Change-Id: I5bafe6927a8dc2a3e25734cb941fd9fce9a8d139
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4031729
Commit-Queue: Ben Hamilton <benhamilton@google.com>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Copy of crrev.com/c/3952963.
Fixes locking not working on some Android filesystems due to flock not
being available. Instead, we now use the same approach as Fuchsia with
a dedicated lock file. This is an issue when running tests on
non-rooted Android devices, as we need files to be written to a
location accessible without root, but the chosen location might not
have flock support.
Bug: chromium:1358240
Change-Id: Ie910481be472403a8b0e9e36100594b0618f85e6
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3999273
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
sed -i '' -E -e 's/Copyright (.+) The Crashpad Authors\. All rights reserved\.$/Copyright \1 The Crashpad Authors/' $(git grep -El 'Copyright (.+) The Crashpad Authors\. All rights reserved\.$')
Bug: chromium:1098010
Change-Id: I8d6138469ddbe3d281a5d83f64cf918ec2491611
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3878262
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
registration_protocol_win.h includes <string>, which adds an
unacceptable dependency on libc++ in //components/crash/win:chrome_wer
in Chrome as that file is included in crashpad_wer.cc. Rather than
remove <string>, which would require doing a lot of transitive
refactoring work in Crashpad, we just extract the data structures into
another file, as crashpad_wer.cc only includes
registration_protocol_win.h for its struct definitions.
Bug: chromium:1357827
Change-Id: Ic20c2952be07ea75d063702cd346cdca0ab65038
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3864251
Commit-Queue: Alan Zhao <ayzhao@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
* crashpad_http_transport_impl is "socket" when targeting Fuchsia
so the dependency on //third_party/curl:libcurl isn't actually
ever added - we might as well remove it to prevent confusion
Bug: fuchsia:107235
TESTED=`fx build` in Fuchsia checkout
Change-Id: I75da6e7505f8ab09f9978472e93c48600f4c35cb
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3840964
Commit-Queue: Francois Rousseau <frousseau@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This adds a runtime exception helper (& test module) for Windows and
plumbing to allow the module to be registered by the crashpad client,
and to trigger the crashpad handler. Embedders can build their own
module to control which exceptions are passed to the handler.
See: go/chrome-windows-runtime-exception-helper for motivation.
When registered (which is the responsibility of the embedding
application), the helper is loaded by WerFault.exe when Windows
Error Reporting receives crashes that are not caught by crashpad's
normal handlers - for instance a control-flow violation when a
module is compiled with /guard:cf.
Registration:
The embedder must arrange for the full path to the helper to
be added in the appropriate Windows Error Reporting\
RuntimeExceptionHelperModules registry key.
Once an embedder's crashpad client is connected to a crashpad
handler (e.g. through SetIpcPipeName()) the embedder calls
RegisterWerModule. Internally, this registration includes handles
used to trigger the crashpad handler, an area reserved to hold an
exception and context, and structures needed by the crashpad handler.
Following a crash:
WerFault.exe handles the crash then validates and loads the helper
module. WER hands the helper module a handle to the crashing target
process and copies of the exception and context for the faulting thread.
The helper then copies out the client's registration data and
duplicates handles to the crashpad handler, then fills back the various structures in the paused client that the crashpad handler will need.
The helper then signals the crashpad handler, which collects a dump then
notifies the helper that it is done.
Support:
WerRegisterExceptionHelperModule has been availble since at least
Windows 7 but WerFault would not pass on the exceptions that crashpad
could not already handle. This changed in Windows 10 20H1 (19041),
which supports HKCU and HKLM registrations, and passes in more types of
crashes. It is harmless to register the module for earlier versions
of Windows as it simply won't be loaded by WerFault.exe.
Tests:
snapshot/win/end_to_end_test.py has been refactored slightly to
group crash generation and output validation in main() by breaking
up RunTests into smaller functions.
As the module works by being loaded in WerFault.exe it is tested
in end_to_end_test.py.
Bug: crashpad:133, 866033, 865632
Change-Id: Id668bd15a510a24c79753e1bb03e9456f41a9780
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3677284
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
This is a reland of 460943dd9a71dc76f68182a8ede766d5543e5341
Original change's description:
> The DoubleForkAndExec() function was taking over 622 milliseconds to run
> on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
> some custom traces and found that the fork() syscall is the bottleneck
> here, i.e., the first fork() takes around 359 milliseconds and the
> nested fork() takes around 263 milliseconds. Replacing the nested fork()
> and exec() with posix_spawn() reduces the time consumption to 257
> milliseconds!
>
> See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
> slow on macOS and why posix_spawn() is a better replacement.
>
> Another point to note is that even base::LaunchProcess() from Chromium
> calls posix_spawnp() on macOS -
> 8f8d82dea0:base/process/launch_mac.cc;l=295-296
The reland isolates the change to non-Android POSIX systems because
posix_spawn and posix_spawnp are available in Android NDK 28, but
Chromium is building with version 23.
Change-Id: If44629f5445bb0e3d0a1d3698b85f047d1cbf04f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3721655
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This reverts commit 460943dd9a71dc76f68182a8ede766d5543e5341.
Reason for revert: This fails to compile in Chromium Android.
posix_spawn and posix_spawnp are available in Android NDK 28, but
Chromium is building with version 23.
https://ci.chromium.org/ui/p/chromium/builders/try/android_compile_dbg/1179765/overview
Original change's description:
> posix: Replace DoubleForkAndExec() with ForkAndSpawn()
>
> The DoubleForkAndExec() function was taking over 622 milliseconds to run
> on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
> some custom traces and found that the fork() syscall is the bottleneck
> here, i.e., the first fork() takes around 359 milliseconds and the
> nested fork() takes around 263 milliseconds. Replacing the nested fork()
> and exec() with posix_spawn() reduces the time consumption to 257
> milliseconds!
>
> See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
> slow on macOS and why posix_spawn() is a better replacement.
>
> Another point to note is that even base::LaunchProcess() from Chromium
> calls posix_spawnp() on macOS -
> 8f8d82dea0:base/process/launch_mac.cc;l=295-296
>
> Change-Id: I25c6ee9629a1ae5d0c32b361b56a1ce0b4b0fd26
> Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Mark Mentovai <mark@chromium.org>
Change-Id: I7f6161bc4734c50308438cdde1e193023ee9bfb8
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3719439
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
The DoubleForkAndExec() function was taking over 622 milliseconds to run
on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
some custom traces and found that the fork() syscall is the bottleneck
here, i.e., the first fork() takes around 359 milliseconds and the
nested fork() takes around 263 milliseconds. Replacing the nested fork()
and exec() with posix_spawn() reduces the time consumption to 257
milliseconds!
See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
slow on macOS and why posix_spawn() is a better replacement.
Another point to note is that even base::LaunchProcess() from Chromium
calls posix_spawnp() on macOS -
8f8d82dea0:base/process/launch_mac.cc;l=295-296
Change-Id: I25c6ee9629a1ae5d0c32b361b56a1ce0b4b0fd26
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Linking crashpad (//third_party/crashpad/crashpad:util) target
into a target built for a secondary toolchain could cause noop
build failure because of an incorrect `include_dirs` directive.
The library depends on a generated buildflag, which when in a
secondary toolchain is generated to $root_gen_dir, a directory
that includes the toolchain name (except for the primary one).
The target added $root_build_dir/gen to its `include_dirs`
which is equal to $root_gen_dir for the primary toolchain, but
distinct for secondary toolchain.
Moreover, `include_dirs` define directly in a `source_set` are
placed before any `include_dirs` values inherited from configs.
This means that $root_build_dir/gen was before $root_gen_dir in
the list ($root_gen_dir is inherited from default config when
building Chromium).
The result is that building any crashpad files would result in
them trying to first include the version of the buildflag that
was generated for the primary toolchain, and if not found, using
the correct one. This was then recorded in the depfile generated
by the compiler.
This meant that it was possible for the build to be incorrect
(as the content of the buildflag may be different between the
two toolchains) and cause flaky noop failures (as the buildlag
generation for the primary toolchain and the compilation of
the source file for the secondary toolchain are unordered, but
a dependency was recorded via the depfile leading ninja to
report a dirty build).
The fix is simple, use the correct value $root_gen_dir in the
`include_dirs` directive.
Fixed: chromium:1314711
Change-Id: Icba521313e4105713e66fa576d730b00c7e74c21
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3579401
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
iOS applications may be terminated with the exception code 0xdead10cc
when holding on to file locks in the shared container during suspension.
One approach to minimize this is to request additional background
execution time to complete the locking operation (in this case the
CrashReportUpload thread and the PruneIntermediateDumpsAndCrashReports
thread).
Bug: crashpad:400
Change-Id: I4192ae1a92646ea337a09ac071e49761ab2d3860
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3517966
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Crashpad currently has a circular dependency: client->snapshot->client.
The dependency from snapshot -> client only exists to pull in a single
constant for Windows (CrashpadClient::kTriggeredExceptionCode), so this
change breaks the dependency by splitting the constant out into a new
file util/win/exception_codes.h.
Change-Id: I6b74b367df716e097758e63a44c53cb92ea5e04d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3450763
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
From the Fuchsia build:
```
ERROR at //third_party/crashpad/util/BUILD.gn:658:7: Undefined identifier.
defines += [ "CRASHPAD_USE_BORINGSSL" ]
^------
See //src/developer/forensics/crash_reports/BUILD.gn:127:5: which caused the file to be included.
"//third_party/crashpad/util",
^----------------------------
```
Change-Id: I1f563e5bb599b3a7a83ee8211037ee1d7464bd62
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3370891
Reviewed-by: Francois Rousseau <frousseau@google.com>
Commit-Queue: Francois Rousseau <frousseau@google.com>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Change IOSIntermediateDumpReader to take a new interface that can be
backed by a FilePath (as it is now) or a StringFile byte array, which
can be useful for tests, especially with fuzzing.
Change-Id: I02a25cfb7cd204975d1bcce80201bd10944f3f2e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3270755
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Only the handler uses util/net. After
8342e6bd613a5b2e44eca1d74288e3115ccef139, the introduction of an
Objective-C class caused Chromium to emit duplicate class defintion
warnings in the component build.
Bug: chromium:1270609
Change-Id: I2770528347aef406bb21a79d295f702498f7b37e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3290276
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This effectively reverts f0ee5f0efee651ab82aa854761f107193b3db5de, but
updates the subclass with the new required NSStream methods. Crashpad
switched to using CFReadStream because NSInputStream required overriding
two private methods of NSInputStream in order to use it with
NSURLConnection. With Mac OS X 10.11 (the earliest that Chromium
supports), this is no longer the case. On iOS, using the private
CFReadStreamCreate() API is not permissible. Switch back to using a
custom NSInputStream subclass instead.
Bug: crashpad:382
Change-Id: I92b1260f49c6fa6c304475f7dc9b27ae1a5f35c4
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3271448
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Manage the intermediate minidump generation, and own the crash report
upload thread and database.
Change-Id: I272d790a827cd13f6872e56f4675f366d13719c5
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3087721
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
More cleanly integration the ObjExceptionPreprocessor with the
Crashpad client and in process handler, to record bought
'caught' and 'uncaught' NSExceptions.
Bug: crashpad: 31
Change-Id: I77a77ca6d893cdc74da476c1888d9bcb338339d8
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2920851
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This will accommodate moving third_party/mini_chromium around.
The default location is unchanged for now.
There are GN variables that may need to be updated when Fuchsia's source
re-organizes its layout:
* mini_chromium_source_parent : this contains a BUILD.gn with groups and
encloses the mini_chromium_source_root. This is controlled by the
structure of the project that depends on this project.
* _mini_chromium_source_root : this is what is normally checked out from
git, the upstream source directory
* mini_chromium_import_root : points inside source_root to make GN files
accessible.
This first step breaks out case logic for "if (crashpad_is_in_fuchsia)"
even if the value is unchanged for now. This will faciliate a smaller
change when Fuchsia re-structures third_party sources.
Change-Id: I09e5362f4be8fdb440e3891422881b1053052341
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3062424
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Due to the limitations of in-process handling, an intermediate dump file
is written during exceptions. The data is streamed to a file using only
in-process safe methods. The file format is similar to binary JSON,
supporting keyed properties, maps and arrays.
- Property [key:int, length:int, value:intarray]
- StartMap [key:int], followed by repeating Properties until EndMap
- StartArray [key:int], followed by repeating Maps until EndArray
- EndMap, EndArray, EndDocument
Similar to JSON, maps can contain other maps, arrays and properties.
Once loaded, the binary file is read into a set of data structures that
expose the data, maps and arrays.
Bug: crashpad: 31
Change-Id: I43a19204935303afd753c8c7090c54099634ccd6
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2870807
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Adds wrapper to vm_read and vm_deallocate memory to allow for safe
in-process memory reads during crashes.
Also adds a logging utility safe for in-process exception handling.
Bug: crashpad: 31
Change-Id: I658f3181cbec40a79e304b7306466e10c003564f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2875349
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
There's no default curl available when building on host Linux in the
Fuchsia tree, so add an explicit dependency when using the curl
transport in Fuchsia.
Change-Id: I0afe5e2cc8ea0a70f3ef4e1635d4d808237c93b6
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2832147
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
The //build/confic/mac/BUILD.gn which defines this target does not
build properly in some cronet ios build configurations, and the
dependency is not necessary for ios builds.
Fixed: 1161219
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2656759
Commit-Queue: Ken Rockot <rockot@google.com>
Auto-Submit: Ken Rockot <rockot@google.com>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#848224}
Message-Id: Merged from chromium a9f64a9dbf42e411a38e3c93b131984a0a02a84a
Change-Id: Ifd03c41d42b3756cb77bb7cc3ece5d3f23b1262d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2818147
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
This particular action was crashing when being traced.
Bug: fuchsia:68780
Change-Id: Ia83d48b2a88f53bd8e139ea9c787429f93a24533
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2662398
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This change removes several unaligned accesses, as well a null pointer
offset and an out of bounds array access.
Bug: fuchsia:46805
Change-Id: I0110d0b7faf672655d978894b868760eee7b2988
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2583025
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
When using the new Goma RBE and use_system_xcode, the referenced .defs
input files are located below the root build directory and so are
considered build outputs. The sdk_inputs target is an empty action that
lets GN consider them to be generated outputs.
Bug: chromium:1157103
Change-Id: I38a959d2c00c20fa403a1c15b1eac69ef2043d5d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2582922
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Includes DEPS roll of mini_chromium:
f0bd14b Pull build_config.h source set into separate build file
65fb5c9 Update path to win_helper after moving to build/config
Change-Id: Ic9f5c68e2cebd8bf86492766684bdb422da1aa9e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2426989
Reviewed-by: Mark Mentovai <mark@chromium.org>
Because of the multiple-worlds building of the Crashpad code in the
Fuchsia tree (with the Fuchsia BUILDCONFIG.gn in particular) there's no
good location to globally disable Wconversion for all of crashpad.
This can be somewhat-improved by using a GN template
crashpad_static_library() similar to the existing crashpad_executable()
template.
Includes mini_chromium DEPS roll:
68da43e Fix a couple trucation warnings
88ce866 build: set include dirs
Bug: fuchsia:58162
Change-Id: I638fcf858c35b9a858ca2c410636f8c99603aed2
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2411131
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
CFI attempts to verify that the dynamic type of a function object
matches the static type of the function pointer used to call it.
https://clang.llvm.org/docs/ControlFlowIntegrity.html#indirect-function-call-checking
However, the analyzer does not have enough information to check
cross-dso calls. In these instances, CFI crashes upon calling the
function with an error like:
pthread_create_linux.cc:60:16: runtime error:
control flow integrity check for type
'int (unsigned long *, const pthread_attr_t *, void *(*)(void *), void *)'
failed during indirect function call
(/lib/x86_64-linux-gnu/libpthread.so.0+0x9200):
note: (unknown) defined here pthread_create_linux.cc:60:16:
note: check failed in crashpad_handler,
destination function located in /lib/x86_64-linux-gnu/libpthread.so.0
Change-Id: Ib29dabfe714f2ee9cc06a5d17e6899ff81a06df4
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2339332
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
When building for macOS and configured with target_cpu =
"mac_universal", bi-architecture x86_64/arm64 output will be produced.
mac_universal is, so far, a “Crashpad special” that will only work with
mini_chromium and the standalone Crashpad build, and not the in-Chromium
build. It exists to support Keystone, which intends to ship as
x86_64/arm64 universal.
Includes:
Update mini_chromium to e0008f2714a76c7f2a3854fa75774427a886d6b9
e0008f2714a7 mac-arm64: Allow target_cpu = "mac_universal" to create
universal builds
Bug: crashpad:345
Change-Id: I5ff2dce5ffae58186e33757aa94587f8eca20b99
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2387410
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
MacOSXMinorVersion reported just the “y” value for an OS version 10.y.z.
This is no longer sufficient to identify OS versions accurately in macOS
11. A new MacOSVersionNumber function reports the full OS version as
“xxyyzz” for an OS version x.y.z. This is the same format used by
<Availability.h> __MAC_* macros since 10.10.
MacOSXVersion is also renamed to MacOSVersionComponents for
disambiguation and proper modern nomenclature.
Bug: crashpad:347
Test: crashpad_snapshot_test SystemSnapshotMacTest.OSVersion, crashpad_util_test MacUtil.MacOSVersionNumber
Change-Id: I66421954f021c0627095474cb26359970fcd9101
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2386386
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
