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
