OpenVINO segfaults when setting some properties

[nbigaouette]

I want to set some OpenVINO properties but OpenVINO crashes when doing so. I get a segfault when setting RwPropertyKey::LogLevel on the core, and a stack overflow (!?) when setting it for a compiled model. I get similar crashes when trying to set other properties, like RwPropertyKey::HintExecutionMode, RwPropertyKey::HintPerformanceMode, or even RwPropertyKey::InferenceNumThreads.

Here's an minimal example:

// export DYLD_LIBRARY_PATH=/opt/homebrew/Cellar/openvino/2025.3.0_1/lib

use openvino::Core;

fn main() {
    let device = openvino::DeviceType::CPU;
    let mut core = Core::new().unwrap();

    let level = "debug";

    // This segfaults
    core.set_property(&device, &openvino::RwPropertyKey::LogLevel, level)
        .unwrap();

    let model = core
        .read_model_from_file(
            "mobilenet.xml", // b28eafd9f8cdf3e265dae4be2eacc4849c0d4693fde584ceca3541bcb4d79e6f
            "mobilenet.bin", // 8371f708ef167a783ed01fc6635f4f05e76f720db95e954aff3cba3ed4f29924
        )
        .unwrap();

    // This crashes with:
    //      thread 'main' has overflowed its stack
    //      fatal runtime error: stack overflow, aborting
    let mut compiled_model = core.compile_model(&model, device).unwrap();
    compiled_model
        .set_property(&openvino::RwPropertyKey::LogLevel, level)
        .unwrap();

    println!("Done");
}

This is on macOS 15.7, using openvino 2025.3.0 from homebrew and openvino-rs version 0.9.1 with the runtime-linking cargo feature.

I tried to debug this with lldb but homebrew's version does not have debug symbols. Even building it manually I couldn't get much information.

[nbigaouette]

For the example above, rust-lldb shows the crash at this line: https://github.com/intel/openvino-rs/blob/main/crates/openvino-sys/src/linking/runtime.rs#L115 with EXC_BAD_ACCESS (code=1, address=0x0).

[nbigaouette]

I was finally able to build openvino myself with debug symbols (had to disable ONNX support with -DENABLE_OV_ONNX_FRONTEND so that it wouldn't need protobuf which fails the build).

The issue happens in the call to the GET_PROPERTY_FROM_ARGS_LIST macro here: https://github.com/openvinotoolkit/openvino/blob/2025.3.0/src/bindings/c/src/ov_core.cpp#L227
The macro is defined here: https://github.com/openvinotoolkit/openvino/blob/2025.3.0/src/bindings/c/src/common.h#L34
Debugging a macro is not fun... :(

Here's the backtrace:

  * frame #0: 0x00000001008708c0 libopenvino_c.2025.3.0.dylib`::ov_core_set_property(const ov_core_t *, const char *, ...) [inlined] unsigned long std::__1::__constexpr_strlen[abi:ne190102]<char>(__str=0) at constexpr_c_functions.h:66:10 [opt]
    frame #1: 0x00000001008708c0 libopenvino_c.2025.3.0.dylib`::ov_core_set_property(const ov_core_t *, const char *, ...) [inlined] std::__1::char_traits<char>::length[abi:ne190102](__s=0) at char_traits.h:229:12 [opt]
    frame #2: 0x00000001008708c0 libopenvino_c.2025.3.0.dylib`::ov_core_set_property(const ov_core_t *, const char *, ...) [inlined] std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::basic_string[abi:ne190102]<0>(this=0x000000016fdfdea8, __s=0) at string:1062:17 [opt]
    frame #3: 0x00000001008708c0 libopenvino_c.2025.3.0.dylib`::ov_core_set_property(const ov_core_t *, const char *, ...) [inlined] std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::basic_string[abi:ne190102]<0>(this=0x000000016fdfdea8, __s=0) at string:1060:58 [opt]
    frame #4: 0x00000001008708c0 libopenvino_c.2025.3.0.dylib`ov_core_set_property(core=0x000000014b104440, device_name=5556421472) at ov_core.cpp:227:9 [opt]
    frame #5: 0x0000000100217944 ov-log`openvino_sys::generated::functions::ov_core_set_property(core=0x000000014b104440, device_name=5556421472, property_key=5556421488, property_value=5556421504) at runtime.rs:115:17
[...]

On macOS, the crash happens in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.5.sdk/usr/include/c++/v1/__string/constexpr_c_functions.h inside the __constexpr_strlen() template:

template <class _Tp>
inline _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14 size_t __constexpr_strlen(const _Tp* __str) _NOEXCEPT {
  static_assert(__is_char_type<_Tp>, "__constexpr_strlen only works with char and char8_t");
  // GCC currently doesn't support __builtin_strlen for heap-allocated memory during constant evaluation.
  // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70816
  if (__libcpp_is_constant_evaluated()) {
#if _LIBCPP_STD_VER >= 17 && defined(_LIBCPP_COMPILER_CLANG_BASED)
    if constexpr (is_same_v<_Tp, char>)
      return __builtin_strlen(__str);
#endif
    size_t __i = 0;
    for (; __str[__i] != '\0'; ++__i)
      ;
    return __i;
  }
  return __builtin_strlen(reinterpret_cast<const char*>(__str));
}

The call to __constexpr_strlen() is done with __str being null. There's something in the GET_PROPERTY_FROM_ARGS_LIST that builds a string will a null pointer...

So I inlined the macro content since it doesn't even take arguments and recompiled openvino. The crash happens at the first line of the macro std::string property_key = va_arg(args_ptr, char*);. Printing the vlaue of args_ptr shows the null:

p args_ptr
(va_list) 6171910112
p *args_ptr
(char) 0

[jlb6740]

Hi @nbigaouette, thanks for bringing this to our attention. We don't have your setup to reproduce exactly (no macos), but @rahulchaphalkar pointed to trying this on Linux to check if there is a version mismatch that is causing issue there. We'll try to reproduce this there first but, have you tried yourself this example on any other platform?

[nbigaouette]

My first try at running this under Linux was not successful. Here's what I did:

# Launch an Ubuntu 22 container
docker run -it --rm -v $(PWD):/pwd --workdir=/pwd ubuntu:jammy
# Install required packages
apt update && apt install curl build-essential
# Install Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
. "$HOME/.cargo/env"
# Download and extract OpenVINO archive
curl -LO "https://storage.openvinotoolkit.org/repositories/openvino/packages/2025.3/linux/openvino_toolkit_ubuntu22_2025.3.0.19807.44526285f24_arm64.tgz"
tar -zxvf openvino_toolkit_ubuntu22_2025.3.0.19807.44526285f24_arm64.tgz
# Copy libs into target dir
cp openvino_toolkit_ubuntu22_2025.3.0.19807.44526285f24_arm64/runtime/lib/aarch64/* target/debug/
# Run
export RUST_LOG="trace"
cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/ov-log`
[2025-10-14T14:13:10Z INFO  openvino_finder] Attempting to find library: libopenvino_c.so
[2025-10-14T14:13:10Z DEBUG openvino_finder] Searching in: /pwd/target/debug/deps/libopenvino_c.so
[2025-10-14T14:13:10Z DEBUG openvino_finder] Searching in: /pwd/target/debug/libopenvino_c.so
[2025-10-14T14:13:10Z INFO  openvino_finder] Found library at path: /pwd/target/debug/libopenvino_c.so

thread 'main' panicked at src/main.rs:27:65:
called `Result::unwrap()` on an `Err` value: GeneralError
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The dreaded "GeneralError" is not helping much. But, the code doesn't crash. Setting the RwPropertyKey::LogLevel property succeeded (even though I don't see any OpenVINO logs).

EDIT: Note that all this is on the macbook pro M3, so both the archive downloaded and the Ubuntu image are aarch64 (arm64).

[rahulchaphalkar]

After investigation, here's what happens - openvino is being given an unexpected value for a key, in this case "debug"/"DEBUG" is the unexpected value for LOG_LEVEL, it should be LOG_DEBUG. Refer here https://github.com/openvinotoolkit/openvino/blob/c165ab738d2b6f43fe680cf9b43a17db3f819d43/src/inference/include/openvino/runtime/properties.hpp#L669
If you attach a debugger, it shows that it reaches this line
I suspect running this test for native c++ openvino in debug mode would yield the right error messages. I agree a General Error here is not informative.
Let me know if this works.
Edit - Uninformative error message is bad, but segfault is worse. I'll keep this issue open for now. I have an ubuntu system which didn't segfault, but need to see whats going on with mac.

[rahulchaphalkar]

The error stemming from compiled_model.set_property() still exists, the above suggestion solves for me the set_property for core. Will investigate this part further.

[nbigaouette]

Thanks for looking into this!

On macos (aarch64-apple-darwin) I still get the segfault when using LOG_TRACE instead of TRACE (and every other LOG_* values). I also still get the fatal runtime error: stack overflow, aborting when calling compiled_model.set_property() (after having commented-out the core.set_property() call).

Inside docker (aarch64-unknown-linux-gnu) the call to core.set_property() passes when using either TRACE or LOG_TRACE. But, if I used TRACE for the log value core.compile_model() returns an error (GeneralError). If I use LOG_TRACE it succeeds. I believe that's the Unsupported log level exception you caught in a debugger (I don't have debug symbols for the built archive so can't verify on my side).

[rahulchaphalkar]

the call to core.set_property() passes when using either TRACE or LOG_TRACE. But, if I used TRACE for the log value core.compile_model() returns an error (GeneralError). If I use LOG_TRACE it succeeds

That has been my observation too, any call after the core.set_property (which includes core, like core.get_property) fails if the property value in incorrect, but doesn't fail in the set_property call itself. I will look into changing this behavior either in the native openvino front, or perhaps having an enum for property values in this repo itself is a good idea, similar to how property keys have to be selected from an enum, so that folks don't hit this error during run time but rather during build (and better error message).

I wanted to look in to compiled_model.set_property() failure too. On a related note, we have explicitly disabled passing compiled model properties at the time of model compilation as can be seen here mostly due to not wanting to deal with variadic args in rust.

About the segfault - are you expriencing this in the absence of compiled_model.set_property? If you only do core.set_property without any other properties set for compiled model (but still doing a core.compile_model) do you get a segfault?

[rahulchaphalkar]

More info on this -

I wanted to look in to compiled_model.set_property() failure too

Turns out, OpenVino has not turned on the ability to set properties for a compiled model. And, as previously stated, openvino-rs crate has disabled setting properties during model compilation due to variadic nature of the expected args. So as of now, there is no way to set compiled model properties from this crate.

As for the seg fault on MacOS, I am not able to reproduce it on my Ubuntu/x86 system.

ToDo -

• Allow setting properties during model compilation
• Remove API compiled_model.set_property() as it is disabled in openvino
• Create enum of permitted values for keys like LOG_LEVEL