Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
safe_dump_to fails when called inside signal handler in Android 8 #71
Comments
|
This could be a platform limitation. Could you please check the other signals, for example SIGUSR1 and SIGTERM? I hope that the limitations are only for SIGSEGV. |
|
I'm quite confident that I tried with SIGABRT as well, but I will check with the rest of the signals and post the results. Forgot to mention that |
|
|
|
It seems like if you don't raise a signal, but a signal is raised (e.g. by dereferencing a null pointer) then it succeeds. I will try to do run more tests and debug this as soon as I get some time. |
|
Any success? |
|
Sorry, I haven't made much headway. As I hinted in the last post the problem seems to happen only when the signal is raised by a call to Even when I raise a non-fatal signal (like SIGUSR2) I exit with segmentation fault (this happens with the other signals as well). (lldb) disassemble --pc
libstacktrace-test.so`boost::stacktrace::detail::this_thread_frames::collect:
-> 0xdbfcfc40 <+88>: str r0, [sp, #0xc]
0xdbfcfc42 <+90>: b 0xdbfcfc44 ; <+92> at collect_unwind.ipp:60
0xdbfcfc44 <+92>: ldr r0, [sp, #0x34]
0xdbfcfc46 <+94>: ldr r1, [sp, #0x28]
(lldb) bt
* thread #1, name = 'xample.stacktrace-test', stop reason = signal SIGSEGV: invalid address (fault address: 0x10c)
* frame #0: 0xdbfd9176 libstacktrace-test.so`::_Unwind_VRS_Pop(context=0xea0985d0, regclass=<unavailable>, discriminator=16512, representation=<unavailable>) at Unwind-EHABI.cpp:907
frame #1: 0xdbfd8e00 libstacktrace-test.so`::_Unwind_VRS_Interpret(context=0xea0985d0, data=0xdbfda620, offset=3, len=4) at Unwind-EHABI.cpp:275
frame #2: 0xdbfd9da6 libstacktrace-test.so`libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm>::stepWithEHABI(this=0xea0985d0) at UnwindCursor.hpp:460
frame #3: 0xdbfd9a24 libstacktrace-test.so`libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_arm>::step(this=0xea0985d0) at UnwindCursor.hpp:1339
frame #4: 0xdbfd929c libstacktrace-test.so`(anonymous namespace)::unwindOneFrame(state=0, ucbp=0xea098178, context=<unavailable>) at Unwind-EHABI.cpp:184
frame #5: 0xdbfd96d4 libstacktrace-test.so`_Unwind_Backtrace(callback=(libstacktrace-test.so`boost::stacktrace::detail::unwind_callback(_Unwind_Context*, void*) + 1 at collect_unwind.ipp:32), ref=0xea098a88) at UnwindLevel1-gcc-ext.c:153
frame #6: 0xdbfcfc40 libstacktrace-test.so`boost::stacktrace::detail::this_thread_frames::collect(out_frames=0xea098ad0, max_frames_count=128, skip=1) at collect_unwind.ipp:59And the backtrace (from android logcat piped to stack) looked like this This https://android.googlesource.com/platform/bionic/+log/refs/heads/master/libc/arch-arm/bionic/__restore.S doesn't fill me with confidence about stack unwinders on arm android either. |
Boost versions: 1.65.0, 1.69.0
Platform: Android 8
When calling
safe_dump_toinside a signal handler in Android 8, no file is created. In fact it seems like we don't successfully exit from_Unwind_Backtraceinboost::stacktrace::detail::this_thread_frames::collect. Calling the function outside of compromised context creates the file as expected. Also it succeeds in any context on Android 7.So far I get consistent failures in two different devices (android 8.0, 8.1) and consistent successes in an Android 7 device. I will try to get same phone models in both versions and test it out.
Also I tested to see if I could write a big (100mb) file from the signal handler (something that takes a considerable amount of time) and this completes successfully in all devices.
Minimum Example: https://gist.github.com/Apo-/14c24c27baa86d95fa305e0252ede41f