[Bug]: LLDB doesn’t list or resolve breakpoints for System.load-loaded .so under app private dir on Android (namespace + rendezvous?)
- Dominant language
- No language data
- Stars
- 2.3k
- Forks
- 310
- PR merge metrics
- No merged PRs in 30d
Description
### Description
**Environment**
• Emulator/Android: Android 13 / 14, arm64
• App: android:debuggable="true", extractNativeLibs=false (also tried true for control)
• How .so is loaded:
• System.load("/data/data//files/.../libX.so")
• Also repro with System.loadLibrary() via a custom ClassLoader pointing to the same private dir (both call android_dlopen_ext)
• Toolchain: Android Studio , NDK , lldb-server from NDK, host LLDB
• Launch mode: Debug (lldb-server user = app UID u0_aNNN) / Attach (also repro)
**Repro steps**
1. Put an unstripped libX.so into /data/data//files/... and load it at runtime with System.load(absPath).
2. In LLDB:
```
settings set target.process.stop-on-sharedlibrary-events true
break set -n android_dlopen_ext
break set -n dlopen
log enable lldb dyld
```
3. After the load occurs, run:
```
image list -b
```
Observed: the module is not listed; breakpoints in that library remain pending.
4. /proc//maps shows the library mapped, and the code in the library executes correctly.
5. lldb-server is confirmed to run as the app UID (e.g., u0_aNNN), so it should have permission to read the private dir.
**Expected**
After the rendezvous eAdd/eAddModules events, LLDB should register the newly loaded module so that it appears in image list and breakpoints resolve automatically.
**Actual**
• log enable lldb dyld shows rendezvous activity around the load (eAdd / eAddModules), but the module is not added to the target’s module list.
• image list does not contain the .so from the app private directory, so breakpoints remain pending and symbols don’t resolve.
**Notes**
• Reproduces with both System.load and System.loadLibrary (custom ClassLoader) which call android_dlopen_ext.
• Reproduces regardless of extractNativeLibs setting (true/false).
• lldb-server is running under the app UID, so this does not look like a simple permission issue.
• This may be related to handling of Android linker namespaces / rendezvous on private-dir loads.
### Upstream bug
_No response_
### Commit to cherry-pick
_No response_
### I am using a supported NDK
- [x] I have checked and the NDK I'm using is currently supported
### Affected versions
r27
### Host OS
Mac
### Host OS version
macOS 15.5
### Affected ABIs
arm64-v8a
Contributor guide
Assessment
This issue has not been assessed yet.