Where is RustRover Topic? I cannot remotely debug android app with RustRover LLDB Fails to Attach - No Stop Reply Packet Received

The RustRover topic or discussion for this issue is generally found in the JetBrains RustRover community channels—mainly their official issue tracker, support forum, or YouTrack. Problems like “LLDB fails to attach – No stop reply packet received” during remote debugging (especially with Android apps) are commonly reported there, since LLDB can struggle with attaching to remote processes due to misconfigured debug servers, incompatible NDK versions, or po

transunioncredit login

Hello Antqazw and Rita568mark 

Here's a useful article that helps set up a remotely debuggable Android app with RustRover LLDB: SUPPORT-A-3988 How to remote-debug Android native code with RustRover (lldb-server gdbserver mode)

I hope this helps!

Hello Monica! Thank you for help
I followed  the instructions
RustRover connects but, I cannot even set breakpoints in manual mode 
here is /gdb-server.log for Android Studio and RustRover
https://github.com/antqazw/issue/tree/main

But I can do it in Android Studio (arm64,  real device)

"APP_BIN="/data/data/$APP_ID/lldb-server"; adb run-as $APP_ID $ gdbserver *:$5090 --attach $SELECTED_PID"
 

Hi Antqazw 

I reviewed the info you shared, recreated the example in my environment, and I was able to hit the breakpoints. 

It requires the configuration to match between the device and RustRover. So, I'm preparing an article that describes this case with a full example you will be able to follow step by step. I'll share the link here as soon as it's ready. 

Please stay tuned for the next update of this post.

Hello Antqazw 

Please find all the necessary configurations to set custom breakpoints in the [Guide]: Setup Remote-debugging Android native code with RustRover + lldb-server (gdbserver mode).

Thank you
I've prepared test project https://github.com/antqazw/issue/blob/master/app/src/main/cpp/CMakeLists.txt
Still could not debug it, after your instructions

Hi Antqazw 

I set up and troubleshoot your project and found that the root cause of the problem is the binary file you are pointing to. Below is a more detailed explanation:

I verified that libdummy.so is loaded in the process (the LLDB image list confirms this), but the final libdummy.so that CMake/Corrosion produced does not contain:

• any exported JNI symbols (JNI_OnLoad, Java_…), and
• any debug line info that mentions lib.rs (or any .rs at all).

Without any Rust source paths or function symbols in that .so, LLDB has nothing it can tie your lib.rs breakpoints to. This is something you need to fix in your project, not a RustRover issue. Even Android Studio’s native debugger wouldn’t be able to stop on Rust source lines for this exact libdummy.so, because there’s simply no Rust debug info to use.

Just to confirm, could you please run the next in a terminal window when debug is attached and running and share the output:

cd /path/to/issue

# Unstripped Debug lib for arm64:
ls app/build/intermediates/cxx/Debug/*/obj/arm64-v8a/libdummy.so

# 1) Check for Rust source paths
dwarfdump --debug-line app/build/intermediates/cxx/Debug/*/obj/arm64-v8a/libdummy.so | grep '.rs' | head

# 2) (If you expect JNI from Rust) check for Java_ symbols
nm -C app/build/intermediates/cxx/Debug/*/obj/arm64-v8a/libdummy.so | grep Java_ || echo "no Java_ symbols"

libissue.so not libdummy.so (it is for linking purpose)
Update:

Somehow RustRover fails to find the correct address
Finally get it working in RustRover by manually setting correct address 

Run this script in lldb prompt: 

script import re; res = lldb.SBCommandReturnObject(); lldb.debugger.GetCommandInterpreter().HandleCommand("process plugin packet send qXfer:libraries-svr4:read::0,ffff", res); match = re.search(r'<library name="[^"]*libissue.so"[^>]*/>', res.GetOutput() or ""); print(match.group(0) if match else "libissue.so not found in XML")

It will output: 

<library name="/data/app/~~Ls3xFNCi6RWj4bEygTjqeA==/com.example.rustroverdebugissue-6eJLbtJlcovKLcBCqHhubw==/lib/arm64/libissue.so" lm="0x79a6024fc0" l_addr="0x76e4814000" l_ld="0x76e48ec6b8" />

Then use l_addr="0x76e4814000" in following command, after -s:

target modules load -f "/home/a/AndroidStudioProjects/Issue/app/build/intermediates/cxx/Debug/1r5m2s46/obj/arm64-v8a/libissue.so" -s 0x76e4814000

If I start RustRover with $HOME/.lldbinit containing log enable gdb-remote packets lldb prompt shows:

LLDBFrontend     <  39> send packet: $qXfer:libraries-svr4:read::0,131071#8c
LLDBFrontend     <42478> read packet: $l<library-list-svr4 version="1.0">
...
<library name="/data/app/~~Ls3xFNCi6RWj4bEygTjqeA==/com.example.rustroverdebugissue-6eJLbtJlcovKLcBCqHhubw==/lib/arm64/libissue.so" lm="0x79a6024fc0" l_addr="0x76e4814000" l_ld="0x76e48ec6b8" />
....
</library-list-svr4>#94
LLDBFrontend     <  19> send packet: $Z0,55b1589ef4,4#b8
LLDBFrontend     <   7> read packet: $E09#ae

But somehow RustRover fails to get and set appropriate address

Hi Antqazw 

Thanks a lot for the project and extra details.

I was able to reproduce your setup with libissue.so and confirm that RustRover + LLDB can see the correct module and symbols (including Java_com_example_rustroverdebugissue_MainActivity_stringFromJNI), and that the remote attachment itself works. However, every attempt to insert a breakpoint into the Android process via lldb-server gdbserver fails with error: 9 sending the breakpoint request, so no breakpoints actually resolve or hit even though the symbols and DWARF are present.

This looks like a limitation/bug in the current lldb-server gdbserver flow for this device combination. I’ve filed a new ticket with all the details for the debugger team to investigate support for this scenario. For now, the best workaround is to keep using your existing VS Code/Android Studio configuration for native debugging on this device, and we’ll follow up once we have guidance or fixes on the LLDB remote-debugging side.

So, please subscribe to the ticket IJPL-246166 for further updates and upvote so we can see the real number of affected users.