<div dir="ltr">Hi,<div><br></div><div>we are running into a few issues when resolving local variables. The first issue is that sometimes an argument is marked as <unavailable> by LLDB, for example __$env in frame #2 of this backtrace:</div><div><br></div><div><div>* thread #2: tid = 0xda984, 0x000000010026d464 ThreadTest`[J]com.robovm.debug.server.apps.SleeperThread.run(__$env=0x000000010285d280, __$this=0x000000010283a8e0)V + 72 at SleeperThread.java:12, stop reason = breakpoint 1.1</div><div>  * frame #0: 0x000000010026d464 ThreadTest`[J]com.robovm.debug.server.apps.SleeperThread.run(__$env=0x000000010285d280, __$this=0x000000010283a8e0)V + 72 at SleeperThread.java:12</div><div>    frame #1: 0x000000010030941e ThreadTest`[j]java.lang.Runnable.run()V[Invokeinterface(java/lang/Thread)] + 9 at Thread.java:1</div><div>    frame #2: 0x0000000100307734 ThreadTest`[J]java.lang.Thread.run(__$env=<unavailable>, __$this=0x0000000102817ab0)V + 76 at Thread.java:837</div><div>    frame #3: 0x00000001005bb24e ThreadTest`_call0 + 142 at call0-darwin-x86_64.s:80</div><div>    frame #4: 0x00000001005a181b ThreadTest`callVoidMethod(env=0x000000010285d280, callInfo=0x000000010528cc70) + 155 at method.c:620</div><div>    frame #5: 0x00000001005a12da ThreadTest`rvmCallVoidInstanceMethodA(env=0x000000010285d280, obj=0x0000000102817ab0, method=0x0000000102811320, args=0x000000010528cdd0) + 634 at method.c:759</div><div>    frame #6: 0x00000001005b9d67 ThreadTest`startThreadEntryPoint(_args=0x00007fff5fbff3e0) + 391 at thread.c:360</div><div>    frame #7: 0x00000001005d0fc5 ThreadTest`GC_inner_start_routine(sb=0x000000010528ceb8, arg=0x0000000102863ed0) + 117 at pthread_start.c:57</div><div>    frame #8: 0x00000001005cdeef ThreadTest`GC_call_with_stack_base(fn=0x00000001005d0f50, arg=0x0000000102863ed0) + 63 at misc.c:1860</div><div>    frame #9: 0x00000001005d243f ThreadTest`GC_start_routine(arg=0x0000000102863ed0) + 31 at pthread_support.c:1666</div><div>    frame #10: 0x00007fff8f66f899 libsystem_pthread.dylib`_pthread_body + 138</div><div>    frame #11: 0x00007fff8f66f72a libsystem_pthread.dylib`_pthread_start + 137</div><div>    frame #12: 0x00007fff8f673fc9 libsystem_pthread.dylib`thread_start + 13</div></div><div><br></div><div>This is a context struct that gets passed to all functions in this backtrace. While it's not available for inspection in frame #2, it is available in in previous and subsequent frames (to which it gets passed by Thread.run). The argument is kept in rbx and passed to functions via rdi in the x86_64 assembler code. Any idea why it is marked as unavailable?</div><div><br></div><div>Related to this, we sometimes get very strange pointer values for arguments. E.g. we have a breakpoint in this function:</div><div><br></div><div>void _rvmHookThreadDetaching(Env* env, JavaThread* threadObj, Thread* thread, Object* throwable) {</div><div>    fprintf(stderr, "[DEBUG] %s: Thread %lld detaching\n", LOG_TAG, threadObj->id);</div><div>} </div><div><br></div><div>The breakpoint is a symbol breakpoint on _rvmHookThreadDetaching. Some times, threadObj has an invalid value, e.g. 0x3030303030313035, which is an invalid address, and almost seems like a sort of tomb stone value. The fun part is, that once we continue, the fprintf executes just fine, printing the value of threadObj->id, indicating that the inferior is actually using a valid address instead of the 0x3030303030313035 as reported by LLDB. We are also 100% certain that we never pass in an invalid address to this function (the caller goes on to use the threadObj value in subsequent statements, which would explode if the address was invalid).</div><div><br></div><div>We'd be happy for any pointers :)</div><div><br></div><div>Thanks,</div><div>Mario</div></div>