Hmbown/CodeWhale · error

Android dladdr returned an empty loaded-image path

Error message

Android dladdr returned an empty loaded-image path

What it means

The successor case to a failed dladdr: the call succeeded, but `dli_fname` is null or points at an empty string, so there is no usable path for the loaded image. Both the null check and the empty-bytes check after `CStr::from_ptr` raise this same message. It means the loader resolved the object but declined to name its file — seen with APK-embedded native libraries loaded through nonstandard paths.

Source

Thrown at crates/cli/src/update.rs:276

        .context("failed to read Android executable mappings from /proc/self/maps")?;
    android_loaded_executable_proof_report(&maps, marker, &dladdr_path)
}

#[cfg(target_os = "android")]
fn android_dladdr_path(marker: *const libc::c_void) -> Result<PathBuf> {
    use std::os::unix::ffi::OsStrExt;

    let mut info = std::mem::MaybeUninit::<libc::Dl_info>::zeroed();
    // SAFETY: `marker` points to a function in this loaded image and `info`
    // points to writable storage for the duration of the call.
    let found = unsafe { libc::dladdr(marker, info.as_mut_ptr()) };
    if found == 0 {
        bail!("Android dladdr could not locate the updater's loaded image");
    }
    // SAFETY: A non-zero dladdr result initializes `info`.
    let info = unsafe { info.assume_init() };
    if info.dli_fname.is_null() {
        bail!("Android dladdr returned an empty loaded-image path");
    }
    // SAFETY: `dli_fname` is a NUL-terminated string owned by the dynamic
    // loader and remains valid while this image is loaded.
    let bytes = unsafe { CStr::from_ptr(info.dli_fname) }.to_bytes();
    if bytes.is_empty() {
        bail!("Android dladdr returned an empty loaded-image path");
    }
    Ok(PathBuf::from(OsStr::from_bytes(bytes)))
}

#[cfg(any(target_os = "android", all(test, unix)))]
#[derive(Debug, Clone, PartialEq, Eq)]
struct AndroidImageMapping {
    start: u64,
    end: u64,
    device_major: u32,
    device_minor: u32,
    inode: u64,

View on GitHub (pinned to 0c42157ee5)

Solutions

1. Skip self-update on this platform: install/upgrade via the package manager or by replacing the binary manually with a verified release asset
2. Run codewhale from a real filesystem path (extract from APK to $PREFIX/bin) so the loader can name the image, then retry update
3. File an upstream report with the Android loader details so the path-resolution strategy can be extended

#!/usr/bin/env bash
# dladdr cannot name APK-embedded images; ensure codewhale runs from a real path
bin="$PREFIX/bin/codewhale"
[ -x "$bin" ] || { echo "install codewhale to $bin before using self-update" >&2; exit 1; }
codewhale update

# shell: fall back to verified manual replacement
if ! codewhale update; then
  curl -fLO <official-release-url>/codewhale-android-arm64
  sha256sum -c checksums.txt --ignore-missing && install -m 0755 codewhale-android-arm64 "$PREFIX/bin/codewhale"
fi

When it happens

Trigger: Running `codewhale update` on Android where the binary lives inside an APK/lib directory or is loaded via a file descriptor / memfd, leaving `dli_fname` empty; loader configurations that anonymize image paths.

Common situations: Codewhale bundled as an nativeLibrary in an Android app; execution from content-provider or fd-based mounts; some proot/chroot sandboxes that blank out link-map names.

Related errors

• Android dladdr could not locate the updater's loaded image
• Android loaded-image authorities resolved to runtime linker
• Android {authority} identifies runtime linker `{}`; refusing
• loaded-image mapping for updater marker is not executable
• loaded-image mapping for updater marker has no file inode

AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20). Data as JSON: /api/errors/5447bbe938fd45ea. Report an issue: GitHub.