These should only be used on host binaries for more detailed crash reports.
Installing the handler on targets (iOS/Android) may cause use to break existing
crash reporting mechanisms users may have installed themselves in the process.
This should work on Darwin & Linux for now.
Doing something like int* a = nullptr; *a = 12; or abort or tripping an
assertion should print something the following before program termination. We
can tweak the report further if necessary.
```
[ERROR:flutter/fml/backtrace.cc(110)] Caught signal SIGSEGV during program execution.
Frame 0: 0x10658342c void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*)
Frame 1: 0x106555070 void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*)
Frame 2: 0x106554f81 testing::Test::Run()
Frame 3: 0x106555dc3 testing::TestInfo::Run()
Frame 4: 0x1065570a1 testing::TestSuite::Run()
Frame 5: 0x106562a55 testing::internal::UnitTestImpl::RunAllTests()
Frame 6: 0x10658c22c bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*)
Frame 7: 0x1065625c3 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*)
Frame 8: 0x106562445 testing::UnitTest::Run()
Frame 9: 0x105c8dc33 RUN_ALL_TESTS()
Frame 10: 0x105c8dbe6 main
Frame 11: 0x7fff7c2dc3d5 start
```
Known issue: This routines that generate the stack trace are not signal safe.
But since we only use the same before the process is terminating, this ought to
be fine. I’ll work in a separate patch to convert all the internals to be signal
safe. In the meantime, this will help us better identify the causes of flakes on
our bots.
Fixes https://github.com/flutter/flutter/issues/50244
This was only necessary when the Engine had to build in multiple buildroots
where the sources where checked out at different paths relative to the
buildroot. This is no longer the case and there are already cases GN rules
have been written that mix and match variable usage with the direct
specification of the path to the Flutter sources relative to the sole buildroot.
If the mapping callback is not set or it the callback returns invalid data, ICU initialization will be embedder responsibility.
This affects all embedders and the following have been audited:
* Android: Via a symbol mapping.
* iOS: Via a file mapping.
* Embedder: Via a file mapping.
* Fuchsia: Via a VMO mapping
* Test shells and Flutter tester: Via file mapping with ICU data needing to be next to the executable.
Also adds //flutter/benchmarking which, similar to //flutter/testing, allows for the creation of a benchmarking executable. This is also the target that contains benchmarking utilities.
