Bug: Crash on older arm64_v8a architecture

[laurenspriem]

Describe the bug

This is a continuation of an issue first raised on the usearch repo. To summarize: it seems there's an instruction in SimSIMD that is not supported by the instruction set of some arm64_v8a arch (mobile)devices.

Re-opening this issue since I now (finally) have full access to a device where it's reproducible, so I'm hoping that with me in the feedback loop we'll be able to fix this pretty quickly.

Steps to reproduce

Run usearch (or SimSIMD directly) on a Samsung Galaxy M30 device. Either opening the index or inserting into it causes the issue (no way to tell from logs since it is crashing).
In our case, we are running it through the rust bindings in combination with flutter_rust_bridge on our Flutter app.

Expected behavior

No crash.

SimSIMD version

v6.4.10

Operating System

Android 10

Hardware architecture

Arm

Which interface are you using?

Rust bindings

Contact Details

laurens@ente.io

Are you open to being tagged as a contributor?

• I am open to being mentioned in the project .git history as a contributor

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

[laurenspriem]

From further testing, it seems that just accessing the usearch index already crashes the device:

use usearch::{Index, IndexOptions, MetricKind, ScalarKind};
use std::path::PathBuf;

pub struct VectorDB {
    index: Index,
    path: PathBuf,
}

impl VectorDB {
    #[frb(sync)]
    pub fn new(file_path: &str, dimensions: usize) -> Self {
        let path = PathBuf::from(file_path);
        let file_exists = path.try_exists().unwrap_or(false);

        let mut options = IndexOptions::default();
        options.dimensions = dimensions;
        options.metric = MetricKind::IP;
        options.quantization = ScalarKind::F32;
        options.connectivity = 0; // auto
        options.expansion_add = 0; // auto
        options.expansion_search = 0; // auto

        let index = Index::new(&options).expect("Failed to create index");
        index
            .reserve(1000)
            .expect("Failed to reserve space in index");

        let db = Self { index, path };

        if file_exists {
            println!("Loading index from disk.");
            // Must use load() instead of view() because:
            // - view() creates a read-only memory-mapped view (immutable)
            // - load() loads the index into RAM for read/write operations (mutable)
            // Using view() causes "Can't add to an immutable index" error
            db.index.load(file_path).expect("Failed to load index");
        } else {
            println!("Creating new index.");
            db.save_index();
        }
        db
    }
}

Are there any SimSIMD methods already called when creating the index? Because if not then maybe the issue is not with SimSIMD after all, and we should go back to the orignal issue in usearch?

[laurenspriem]

I've asked Claude to log the CPU capabilities and give an overview of the output, maybe it helps. Here is the information:

  Device Information

  - Model: SM-M305F (Samsung Galaxy M30)
  - Android Version: 10 (API Level 29)
  - CPU Architecture: arm64-v8a
  - Supported ABIs: arm64-v8a, armeabi-v7a, armeabi

  CPU Capabilities (/proc/cpuinfo)

  processor     : 0-5
  CPU implementer       : 0x41
  CPU architecture: 8
  CPU variant   : 0x0
  CPU part      : 0xd03 (Cortex-A53)
  CPU revision  : 4
  Features      : fp asimd evtstrm aes pmull sha1 sha2 crc32

  processor     : 6-7
  CPU implementer       : 0x41
  CPU architecture: 8
  CPU variant   : 0x0
  CPU part      : 0xd09 (Cortex-A73)
  CPU revision  : 2
  Features      : fp asimd evtstrm aes pmull sha1 sha2 crc32

  Notable: The CPU supports standard ARMv8 SIMD (asimd) but does NOT list support for:
  - SVE (Scalable Vector Extension)
  - SME (Scalable Matrix Extension)
  - Any dot product instructions
  - FP16 arithmetic

  OS Security Settings

  - SELinux: Enforcing
  - Seccomp: 0 (not restricted)

  Crash Details from logcat

  Fatal signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x706dce1540
  signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x706dce1540 (*pc=0xd538060b)

  The instruction at fault (0xd538060b) appears to be:
  - d538060b - This is likely an MRS instruction accessing a system register

[ashvardanian]

This is very helpful, @laurenspriem! Must be an issue introspecting CPU capabilities! I think I know where to check 🤗

[ashvardanian]

There might be an issue here:

SimSIMD/include/simsimd/simsimd.h

Lines 488 to 528 in 013e199

	SIMSIMD_PUBLIC simsimd_capability_t _simsimd_capabilities_arm(void) {
	#if defined(_SIMSIMD_DEFINED_APPLE)
	// On Apple Silicon, `mrs` is not allowed in user-space, so we need to use the `sysctl` API.
	unsigned supports_neon = 0, supports_fp16 = 0, supports_bf16 = 0, supports_i8mm = 0;
	size_t size = sizeof(supports_neon);
	if (sysctlbyname("hw.optional.neon", &supports_neon, &size, NULL, 0) != 0) supports_neon = 0;
	if (sysctlbyname("hw.optional.arm.FEAT_FP16", &supports_fp16, &size, NULL, 0) != 0) supports_fp16 = 0;
	if (sysctlbyname("hw.optional.arm.FEAT_BF16", &supports_bf16, &size, NULL, 0) != 0) supports_bf16 = 0;
	if (sysctlbyname("hw.optional.arm.FEAT_I8MM", &supports_i8mm, &size, NULL, 0) != 0) supports_i8mm = 0;
	return (simsimd_capability_t)( //
	(simsimd_cap_neon_k * (supports_neon)) | //
	(simsimd_cap_neon_f16_k * (supports_neon && supports_fp16)) | //
	(simsimd_cap_neon_bf16_k * (supports_neon && supports_bf16)) | //
	(simsimd_cap_neon_i8_k * (supports_neon && supports_i8mm)) | //
	(simsimd_cap_serial_k));
	#elif defined(_SIMSIMD_DEFINED_LINUX)
	// Read CPUID registers directly
	unsigned long id_aa64isar0_el1 = 0, id_aa64isar1_el1 = 0, id_aa64pfr0_el1 = 0, id_aa64zfr0_el1 = 0;
	// Now let's unpack the status flags from ID_AA64ISAR0_EL1
	// https://developer.arm.com/documentation/ddi0601/2024-03/AArch64-Registers/ID-AA64ISAR0-EL1--AArch64-Instruction-Set-Attribute-Register-0?lang=en
	__asm__ __volatile__("mrs %0, ID_AA64ISAR0_EL1" : "=r"(id_aa64isar0_el1));
	// DP, bits [47:44] of ID_AA64ISAR0_EL1
	unsigned supports_integer_dot_products = ((id_aa64isar0_el1 >> 44) & 0xF) >= 1;
	// Now let's unpack the status flags from ID_AA64ISAR1_EL1
	// https://developer.arm.com/documentation/ddi0601/2024-03/AArch64-Registers/ID-AA64ISAR1-EL1--AArch64-Instruction-Set-Attribute-Register-1?lang=en
	__asm__ __volatile__("mrs %0, ID_AA64ISAR1_EL1" : "=r"(id_aa64isar1_el1));
	// I8MM, bits [55:52] of ID_AA64ISAR1_EL1
	unsigned supports_i8mm = ((id_aa64isar1_el1 >> 52) & 0xF) >= 1;
	// BF16, bits [47:44] of ID_AA64ISAR1_EL1
	unsigned supports_bf16 = ((id_aa64isar1_el1 >> 44) & 0xF) >= 1;
	// Now let's unpack the status flags from ID_AA64PFR0_EL1
	// https://developer.arm.com/documentation/ddi0601/2024-03/AArch64-Registers/ID-AA64PFR0-EL1--AArch64-Processor-Feature-Register-0?lang=en
	__asm__ __volatile__("mrs %0, ID_AA64PFR0_EL1" : "=r"(id_aa64pfr0_el1));
	// SVE, bits [35:32] of ID_AA64PFR0_EL1
	unsigned supports_sve = ((id_aa64pfr0_el1 >> 32) & 0xF) >= 1;
	// AdvSIMD, bits [23:20] of ID_AA64PFR0_EL1 can be used to check for `fp16` support

And there is a very similar piece of logic in StringZilla:

https://github.com/ashvardanian/StringZilla/blob/7e33c0c69d1a8e93d15f07923ce75bae6923b295/include/stringzilla/stringzilla.h#L230-L270

Are you cross-compiling and running in QEMU or on a physical device? Any chance you can try calling StringZilla on the same CPU?

[laurenspriem]

There might be an issue here

Thanks for looking into it so quickly! I really hope we can resolve it using a change there or in StringZilla!

Are you cross-compiling and running in QEMU or on a physical device?

I'm running it on a physical device. If QEMU would make debugging easier, could look into it or use the Android Studio emulator instead, but I have a feeling it would be tricky to exactly resemble the Samsung device in terms of arch and instruction set. That said, I have full access to the physical device now so testing on that is pretty easy.

Any chance you can try calling StringZilla on the same CPU?

StringZilla has rust bindings too, so I should be able to easily call it on the same CPU. Which release or branch of StringZilla would you like me to try? And any specific method of StringZilla I should call, or shall I just try some random examples from quickstart?

[ashvardanian]

Random examples from Quick Start is the way, sadly. Thanks!

[laurenspriem]

Sorry for the delay!

So I added a whole bunch of StringZilla methods to the app through the rust bindings and then tried it out on the same device. Turns out then the app already crashes on app startup, so I don't even get to calling the actual methods.
From adb logcat: Fatal signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x6ebcc9d2c4 in tid 32009 (tos.independent), pid 32009 (tos.independent)

So the problem is in the initialization code, not in any specific function, as it happens during library load. I'm assuming this contains that piece of logic similar to SimSIMD that you were referring to, related to CPU instructions?

Is there something else I can test to help you debug it further?

[ashvardanian]

Thanks for all the details, @laurenspriem! I have drafted a solution in StringZilla that may work. If it works for you, I'll bring it to SimSIMD as well 🤗

[laurenspriem]

Thanks a lot! I just tested it out on the device with the latest StringZilla 4.2.1 and indeed it's not crashing on startup anymore, nor is it crashing on any of the methods I tried from quickstart. So I think you've found the fix!

If this could be implemented on SimSIMD (and transitively usearch, where I'm actually using it), that would be great!

[ashvardanian]

Need to take care of a few cross-compilation issues, that have already been taken care of in StringZilla. Will merge right after 🤗