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>
Officially, register X31 does not exist. The code is zeroing out a location
and thus actually needs XZR.
LLVM seems to automatically translate X31 into XZR when compiling the code,
but GCC (tested 7.3.0) refuses to accept the instruction:
../../third_party/crashpad/crashpad/util/misc/capture_context_linux.S: Assembler messages:
../../third_party/crashpad/crashpad/util/misc/capture_context_linux.S:291: Error: operand 1 must be an integer register -- `str x31,[x0,#0xb0]'
Bug: chromium:819294
Change-Id: I85be3923ac56fca6e3ec59d7e22b2223cfc8fa63
Reviewed-on: https://chromium-review.googlesource.com/1078818
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
user_vfp is not declared anymore in sys/user.h, but in specific
internal kernel asm user.h in GLIBC. So building crashpad on ARMEL
with such a GLIBC will fail to build.
Also, sys/ptrace.h will not include the declarations for
PTRACE_GET_THREAD_AREA and PTRACE_GETVFPREG in arm (they are in
asm/ptrace.h and not included from sys/ptrace.h). So provide
compatibility declarations accordingly for arm architecture.
Change-Id: I58ab5274a66d84c0cbc9e9e9b23e0abc37bf67e5
Reviewed-on: https://chromium-review.googlesource.com/996073
Reviewed-by: Mark Mentovai <mark@chromium.org>
Change-Id: I062c853d65c3e89a61920d790d9bc5c993b46fcd
Reviewed-on: https://chromium-review.googlesource.com/884581
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
HTTPBodyStream::GetBytesBuffer returns negative number on error.
Change-Id: I9958fb35d65e894067d71e8f37c30ff8948cd90d
Reviewed-on: https://chromium-review.googlesource.com/366360
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This commit contains the basic structure of the project:
- LICENSE and related files.
- DEPS to check dependencies out into third_party.
- README.crashpad files and .gyp files to accompany third_party
dependencies.
- Infrastructure to run GYP as a gclient hook.
- codereview.settings to enable Rietveld code review.
- Assorted other administrative and dot-files.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/426403002
