[BUG] Cannot launch ndk-lldb in NDK in v26.1.10909125

[cmannett85-arm]

Description

I installed the NDKs via the sdkmanager. On 26.1.10909125 launching ndk-lldb:

~/Android/Sdk/ndk/26.1.10909125$ ./ndk-lldb 
ERROR: Failed to find make in '/home/camman01/Android/Sdk/ndk/26.1.10909125/prebuilt/linux-x86_64/bin/ndkgdb.pyz'

Whilst on 25.2.9519653 (same parent directory, same machine, same sdkmanager install, same terminal):

~/Android/Sdk/ndk/25.2.9519653$ ./ndk-lldb 
ERROR: Could not find AndroidManifest.xml in current directory or a parent directory.
       Launch this script from inside a project, or use --project=<path>.

Looking in the ndkgdb.pyz for 26.1.10909125 the error is from:

def ndk_bin_path():
    return os.path.dirname(os.path.realpath(__file__))

def handle_args():
    ...
    ndk_bin = ndk_bin_path()
    args.make_cmd = find_program("make", [ndk_bin])
    args.jdb_cmd = find_program("jdb", paths)
    if args.make_cmd is None:
        error("Failed to find make in '{}'".format(ndk_bin))
   ...

Looks pretty inoccuous, and running the equivalent Python command yields the expected result:

Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.dirname(os.path.realpath("~/Android/Sdk/ndk/26.1.10909125/prebuilt/linux-x86_64/bin/ndkgdb.pyz"))
'/home/camman01/Android/Sdk/ndk/25.2.9519653/~/Android/Sdk/ndk/26.1.10909125/prebuilt/linux-x86_64/bin'

Comparing it to the previous NDK version, there's no obvious related code change, but the Python file has become a zipapp (hence the change in extension). I suspect the __file__ relates to the embedded script so calling os.path.dirname(..) on it returns the top-level zipapp file rather than its owning directory.

Affected versions

r26

Canary version

No response

Host OS

Linux

Host OS version

Ubuntu 22.04.3 LTS

Affected ABIs

armeabi-v7a, arm64-v8a, x86, x86_64

Build system

ndk-build

Other build system

No response

minSdkVersion

34

Device API level

No response

[DanAlbert]

I swear this isn't the first time I've fixed this problem... Because we had the same problem in ndk-stack but didn't also fix ndk-lldb: #1938.

The report is unfortunately about 20 minutes too late to be fixed in r26c (it's on its way to QA as we speak). This probably justifies an r26d, but that'll be another month or more.

I am curious, what workflow are you using where ndk-lldb is at all useful? IME it's very annoying to get working compared to using Android Studio's debugger (and that isn't really something we can solve because the introspection for gradle just isn't there). We've kept this around because it doesn't cost us much and someone's probably using it, but we've got very little idea why anyone would so we're not really sure how much attention we should be giving it, or for that matter even how to test it appropriately.

[DanAlbert]

The report is unfortunately about 20 minutes too late

Or rather, seeing the time stamp, I went straight to finishing the release this morning and only just got to this part of my inbox 😞 Well, if I'd been on time in the first place it'd have been a few days too late anyway :)

[cmannett85-arm]

I am curious, what workflow are you using where ndk-lldb is at all useful? IME it's very annoying to get working compared to using Android Studio's debugger

Yes it's spectacularly annoying and I hate using it. Unfortunately though I have no choice as the project I'm contributing to uses CMake to manually 'handroll' its server APKs - so Android Studio can't gather the data it needs to run the debugger itself. This isn't the first project I've come across that does this either...

[DanAlbert]

Does https://developer.android.com/studio/debug/apk-debugger not even work? If it doesn't, you should file a bug against Android Studio. The whole point of that feature is to make it possible to debug things that weren't build by Studio.

I'm somewhat amazed that ndk-lldb works for your use case at all. It was only ever built to handle non-gradle ndk-build projects. I don't think we've ever so much as tried using it on a CMake project.

[cmannett85-arm]

You know I hadn't heard of it... I'm not really an Android developer!

It looks great, but unfortunately it can't seem to find the launched package, even though it is running. This was on 2022.3.1.19, but on 2023.1.1.28 it doesn't even launch on the target. I'll open bug after a bit more digging.

[enh-google]

You know I hadn't heard of it... I'm not really an Android developer!

how/where did you find out about ndk-lldb? we've tried to have little notes saying "hey, have you tried the Studio debugger?" everywhere, but we may well have missed some...

(i wonder whether we should make ndk-lldb itself say "have you tried Studio?"!)

[DanAlbert]

enh beat me to it :) At the very least it sounds like I should add "Hey, are you sure you don't want APK debugging?" to the startup of ndk-lldb...

[cmannett85-arm]

how/where did you find out about ndk-lldb?

A colleague at Arm working on a similar-ish application showed me. Clearly we could both do better!

Although I have to say if I did see "hey, have you tried the Studio debugger?" I would just assume that it meant having an Android Studio project. Because the software I work on didn't use AS to create it I don't use AS enough to know what it's capable of.

[DanAlbert]

I'll write the warning a bit more carefully than I did above :)

[vvb2060]

for Windows users

cd ndk\toolchains\llvm\prebuilt\windows-x86_64\python3
..\bin\lldb

now it works

[DanAlbert]

https://r.android.com/c/2974633 fixes the bug and https://r.android.com/2974635 adds a hint to the startup:

**Android Studio's debugger can be used for non-Studio projects.**
See https://developer.android.com/studio/debug/apk-debugger

ndk-lldb is still usable for debugging command line Android tools or
ANT-based app builds, but it was never meant to handle other use
cases. Android Studio can debug your APK even if Android Studio
wasn't used to build the project, and this will be *much* easier
than using ndk-lldb in most circumstances.

[cmannett85-arm]

That's great Dan, thanks! Feel free to close this issue when you're ready.

[cmannett85-arm]

^ Sorry, fat fingers...