Commit 18bdb28ef6 have configured `SIGPROF` handler on Android
to use alternative signal stack to workaround a [bug][1] in Bionic
implementation of `setjmp`. However when implementing the
workaround we have misinterpreted `sigaltstack` documentation
and assumed that `sigaltstack` configures alternative stack
*globally*, similar to how `sigaction` configures the signal handler.
This is not correct: `sigaltstack` configures alternative stack
for the current thread only.
Nevertheless our workaround kinda worked as intended because Bionic's
`pthread_create` actually assigns an individual alternative
stack to each new thread since [Android L][2].
However older version of Bionic (pre [Android 6.0.1][3]) configured
alternative signal stack which was too small for ARM64. This meant
that non-trivial signal handler could easily overflow the stack
and cause a SIGSEGV when hitting a guard page.
This is what we observe in the flutter/flutter#130003: launching
Flutter application with profiler enabled in a ARM64 emulator
running Android 6.0 causes an immediate segfault in the
signal handler.
This CL changes our code to make sure that alternative signal
stack associated with the current thread is present and is large
enough and allocate a new one if it is not.
[1]: b/152210274
[2]: https://android-review.git.corp.google.com/c/platform/bionic/+/62238
[3]: https://android-review.git.corp.google.com/c/platform/bionic/+/172213
[4]: https://github.com/flutter/flutter/issues/130003
TEST=manually on an Android 6.0.0 ARM64 emulator
Cq-Include-Trybots: luci.dart.try:vm-aot-android-release-arm64c-try,vm-ffi-android-release-arm64c-try,vm-ffi-android-release-arm-try
Change-Id: Ib87df25e72ad3f486e90cf2fc6d7f980a8e0b1dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327866
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This relands https://dart-review.googlesource.com/c/sdk/+/205633
but without renaming TARGET_OS_IPHONE to DART_TARGET_OS_IPHONE.
It also changes uses of TARGET_OS_IOS to
DART_TARGET_OS_MACOS_IOS to be consistent with the rest of the
VM.
TargetConditionals.h for XCode 13 defines several
TARGET_OS_* preprocessor symbols that confuse the
Dart build. There is probably a more targeted fix
for this, but renaming the symbols that Dart uses
will also prevent this problem if more symbols
are added to the platform headers in the future.
See: https://github.com/dart-lang/sdk/issues/46499
TEST=It builds.
Change-Id: Ie775c19dd23cfdf5f65e5ebc6ee4ec3a561676fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205860
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
TargetConditionals.h for XCode 13 defines several
TARGET_OS_* preprocessor symbols that confuse the
Dart build. There is probably a more targeted fix
for this, but renaming the symbols that Dart uses
will also prevent this problem if more symbols
are added to the platform headers in the future.
See: https://github.com/dart-lang/sdk/issues/46499
TEST=It builds.
Change-Id: I3b33a03b4a9a14b76d55fe12f8cdefec4b3c3664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205633
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Bionic implementation of setjmp mangles[1] stack pointer - which means
it is unsafe to handle signals on the thread stack (see b/152210274).
Thread interrupter is constantly sending SIGPROF to the Dart thread -
which means with a small probability it might hit the case when we are
inside setjmp. If SP is mangled it might point to random writable memory
or to non-writable region. In the first case we will get a very obscure
memory corruption, and in the second case kernel would send us SIGSEGV
because it fails to deliver original signal.
This bug is the source of the numerous mysterious crashes reported for Flutter,
looking like this:
F/libc (11547): Fatal signal 11 (SIGSEGV), code 128, fault addr 0x0 in tid 11572 (1.ui), pid 11547 (ectivity_change)
...
signal 11 (SIGSEGV), code 128 (SI_KERNEL), fault addr 0x0
...
backtrace:
#00 pc 00018abc /system/lib/libc.so (sigsetjmp+120)
Note the following key points: SIGSEGV has code SI_KERNEL (meaning it
was triggered by kernel - rather than by a hardware fault) and the first
and only frame is inside sigsetjmp (unwinding is obviously also broken
because SP is mangled).
Fixes https://github.com/flutter/flutter/issues/27077
[1] https://android.googlesource.com/platform/bionic/+/refs/heads/master/libc/arch-x86/bionic/setjmp.S#132
Change-Id: I91afa42dbf6575db0cce8e223368b857a49b39b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140643
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Android and Linux use R11 as the FP register in ARM code and R7 in Thumb code. We've been assuming all code in our process is ARM and reading R11 as FP. This made our stack walks fail if they started in Thumb code.
This issue does not arise on iOS, because its ABI uses R7 as the FP register for both ARM and Thumb code.
R=zra@google.com
Review-Url: https://codereview.chromium.org/2965823002 .
Like HOST_ARCH_*, HOST_OS_* describes the OS the VM is running on, which may be different from the OS the VM is generating code for during AOT compilation.
Currently we conflate the two when emitting AOT as assembly, and we get away with it because Flutter only uses assembly for targeting iOS and one can only target iOS from a Mac, but we expect to use assembly for Android as well so native tools can unwind Dart frames.
R=zra@google.com
Review-Url: https://codereview.chromium.org/2750843003 .
Kernel does not clear If-Then execution state bits when entering ARM signal handler which violates requirements imposed by ARM architecture reference. Some CPUs look at these bits even while in ARM mode which causes them
to skip some instructions in the prologue of the signal handler.
To work around the issue we insert enough NOPs in the prologue to ensure that no actual instructions are skipped and then branch to the actual signal handler.
For the kernel patch that fixes the issue see: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6ecf830e5029598732e04067e325d946097519cb
This causes sporadic crashes with SIGILL on some testing devices (e.g. Nexus 7).
R=fschneider@google.com
BUG=
Review URL: https://codereview.chromium.org/1940883002 .
Profiler improvements:
- Track Functions in profile and build Function based trie
- Associate code objects with functions
- Created cpu_profile.dart library
- Major speed improvements for disassembly view
- Fix truncation of disassembly comments
- Ability to get code object ticks from disassembly view
- Inlining mini-map in disassembly view.
- Remove a bunch of unused data from profile service response
- In some cases a caller PC that is better than the PC marker is inserted into the stack trace
- Inlined functions are expanded
- Ability to clear profile
- New flag '--keep_code' which keeps deoptimized code around for use by the profiler.
General fixes:
- Fix caching in service library
- Remove pubspec.yaml before running pub get
R=asiva@google.com, rmacnak@google.com
Review URL: https://codereview.chromium.org//928833003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44067 260f80e4-7a28-3924-810f-c04153c831b5
On arm64, in Dart code, R18(SP) is the stack pointer.
In C++ code, R31(CSP) is the stack pointer.
The profiler must choose the right one when performing
its bounds checks.
This change also fixes a bug in the InvokeDartCode stub
on arm64 so that CSP is set to the Isolate's stack
limit immediately, rather than a bit later. When it was
set a bit later, if a profiler interrupt came in in the
interim, the stack would be smashed.
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org//583683002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@40502 260f80e4-7a28-3924-810f-c04153c831b5
Vyacheslav Egorov