Obsolete
Status Update
No update yet.
Comments
en...@google.com
ag...@google.com
Would you mind sending the APK (and repro instructions, e.g., if there's something to do to make it happen with higher probability) to m i n g y a o (at) g o o g l e . c o m ?
bl...@gmail.com
Sorry for duplicates. I found that It's reproducible while you debugging your application with Android Studio. Usually it happens then I debug some onDraw method. I'll try to come with minimal example soon to share with you.
bl...@gmail.com
Unfortunately I still not able to reproduce it in minimal example. Every time I extract the code that makes it crash from my app to smaller example scope it starts to work. The only major difference between project there it crashes and example app I see from ART POV is that my project uses multidex.
sh...@google.com
Note the method art::Thread::PopDeoptimizationReturnValue was removed in AOSP with https://android-review.googlesource.com/167746 . That may explain why we cannot reproduce on AOSP ToT.
ro...@gmail.com
Is there a workaround. It crashes every time?
ro...@gmail.com
It crashes on Android TV too
ng...@google.com
Mingyao, is that fixed?
cl...@stubbs.me
I see this bug reliably when stepping out of a function that is in a JAR file that has been compiled into the app. Doesn't seem to happen when stepping in project code.
vl...@gmail.com
Also happens when stepping inside project code.
mi...@google.com
PopDeoptimizationReturnValue() is not in ToT anymore. How do we deal with this kind of situation?
lb...@gmail.com
@17 Is this issue related or similar to other native crashes of other devices and Android versions, as I've reported here:
https://issuetracker.google.com/issues/37140362
?
?
mi...@google.com
@18 No. It's supposed to happen under debugger.
lb...@gmail.com
@19 Oh ok.
ng...@google.com
#17: Mingyao, if there's a workaround developers can use for single stepping on M that would be great. Otherwise, we have to assume single-stepping on M is randomly broken and suggest the developers move to debugging on N.
mi...@google.com
I think moving to N is the best suggestion.
lb...@gmail.com
@22 This doesn't seem right.
What if we need to debug on M, as we found an issue on our app on M ?
What if we need to debug on M, as we found an issue on our app on M ?
ng...@google.com
Mingyao, can you answer #23?
ze...@google.com
For what it is worth, we have a few reproduction cases of this issue in the D8/R8 debugger tests (
1. set breakpoint in BreakAtTryAndCatchTest::foo line 10
2. run => hits breakpoint on line 10 (test setup will repeat this twice, but that is not needed to trigger the crash)
3. set breakpoint in BreakAtTryAndCatchTest::main line 31
4. run => causes crash
The DEX code causing the issue is attached. The debugger test session can be found at:https://r8.googlesource.com/r8/+/master/src/test/java/com/android/tools/r8/debug/BreakAtTryAndCatchTestRunner.java
1. set breakpoint in BreakAtTryAndCatchTest::foo line 10
2. run => hits breakpoint on line 10 (test setup will repeat this twice, but that is not needed to trigger the crash)
3. set breakpoint in BreakAtTryAndCatchTest::main line 31
4. run => causes crash
The DEX code causing the issue is attached. The debugger test session can be found at:
ng...@google.com
Mingyao, Seb, I wonder if this code:
https://cs.corp.google.com/aosp-marshmallow/art/runtime/entrypoints/quick/quick_trampoline_entrypoints.cc?type=cs&q=%22SetException(Thread::GetDeoptimizationException())%22&l=648
is the problem, as it doesn't push a new record on tlsptr.deoptimization_return_value_stack.
This means that stepping out of a compiled method is always busted?
is the problem, as it doesn't push a new record on tlsptr.deoptimization_return_value_stack.
This means that stepping out of a compiled method is always busted?
sh...@google.com
Unfortunately I think so. IIRC the issue was fixed after a refactoring of the code in AOSP, thus it does not happen on next releases of Android (N+). But essentially it's missing a new record on the deoptimization stack.
It happens when we return into a compiled method (the caller) which needs to be deoptimized for debugging if:
* we single-step out into that method (the caller)
* we set a breakpoint in that method during its execution (we suspended in a callee method then set the breakpoint in one of its caller).
It seems to match the behavior of step 3 in the test in
Mingyao, can you confirm?
It happens when we return into a compiled method (the caller) which needs to be deoptimized for debugging if:
* we single-step out into that method (the caller)
* we set a breakpoint in that method during its execution (we suspended in a callee method then set the breakpoint in one of its caller).
It seems to match the behavior of step 3 in the test in
Mingyao, can you confirm?
lb...@gmail.com
@25, @26, @27 Guys please have those chats in an email/chat service....
I don't think others can understand much of what you write here...
:)
I don't think others can understand much of what you write here...
:)
mi...@google.com
Nicolas/Seb, I think the deopt context structure was later added and could be chained (to handle another deopt when trying to handle one deopt, during possible class loading triggered by populating deopt shadow frames. Chaining probably is not needed anymore since I think we removed potential class loading when populating deopt shadow frames). It seems to me the issue in code in https://cs.corp.google.com/aosp-marshmallow/art/runtime/entrypoints/quick/quick_trampoline_entrypoints.cc?type=cs&q=%22SetException(Thread::GetDeoptimizationException())%22&l=648 is it doesn't preserve the pending exception. The later code has pending exception in the deopt context, in addition to return result etc. So when it deopts, instead of throwing an exception, it continues at the calling instruction with some illegal result.
mi...@google.com
aj...@google.com
With Mingyao leaving, we have to find new owners for CHA and LSE flavored issues. I am assigning this bug to me for now to get proper ownership for an initial investigation (but I may dispatch this later).
aj...@google.com
sa...@google.com
Thank you for your feedback. We have tried our best to address the issue reported, however our product team has shifted work priority which doesn't include this issue. For now, we will be closing the issue as "Won't Fix (Obsolete)". If this issue still currently exists, we request that you log a new issue along with the latest bug report here: https://goo.gl/TbMiIO and reference this bug for context.
ng...@google.com
Alex, you're now the most familiar in that area. Is the bug obsolete?
Description
Device: Nexus 6p
Android version: 6.0.1
Build number: MMB29P
Stacktrace:
pid: 12057, tid: 12106, name: Core Thread #1 >>> com.example.myapp <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x10
x0 0000000000000000 x1 0000000000000000 x2 0000007f91059600 x3 000000000000000e
x4 0000000000000005 x5 000000000000005d x6 000000000000005e x7 0000007faa4cf000
x8 0000007faa4cfd40 x9 000000000000e980 x10 0000000000054488 x11 00000000000544a8
x12 0000000000000000 x13 0000007faa50f000 x14 0000000000000000 x15 0000007faa501000
x16 0000007faa512eb0 x17 0000007faa501000 x18 0000007faa512f50 x19 0000007f91059698
x20 0000007f91059600 x21 0000007fa713a000 x22 0000007f8f458ec0 x23 0000007f90b7e3e8
x24 0000007f90b7e888 x25 0000007f90b7e4cc x26 0000007f90b7eb80 x27 0000007fa713a000
x28 0000007f90b7e4b4 x29 0000007f90b7e360 x30 0000007fa6c38188
sp 0000007f90b7e360 pc 0000007fa6f5ae10 pstate 0000000080000000
backtrace:
#00 pc 0000000000450e10 /system/lib64/libart.so (art::Thread::PopDeoptimizationReturnValue()+24)
#01 pc 000000000012e184 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+536)
#02 pc 00000000004ce690 /system/lib64/libart.so (artInterpreterToCompiledCodeBridge+212)
#03 pc 00000000002a8e30 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+480)
#04 pc 00000000002abef8 /system/lib64/libart.so (bool art::interpreter::DoInvoke<(art::InvokeType)2, false, false>(art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+268)
#05 pc 00000000000dd6fc /system/lib64/libart.so (art::JValue art::interpreter::ExecuteGotoImpl<false, false>(art::Thread*, art::DexFile::CodeItem const*, art::ShadowFrame&, art::JValue)+22892)
#06 pc 0000000000286840 /system/lib64/libart.so (art::interpreter::EnterInterpreterFromEntryPoint(art::Thread*, art::DexFile::CodeItem const*, art::ShadowFrame*)+96)
#07 pc 000000000053b1a0 /system/lib64/libart.so (artQuickToInterpreterBridge+632)
#08 pc 0000000000127ee4 /system/lib64/libart.so (art_quick_to_interpreter_bridge+100)
#09 pc 000000000012804c /system/lib64/libart.so