[Bug] Panic when assigning zenoh::Session to static or global variable

[gftrobots]

Describe the bug

Description:
On a Raspberry Pi (aarch64, ARM64) running the latest Zenoh (built from source, clean system) and Rust 1.91.1, my application panics during with the following message:

thread <unnamed> panicked at /usr/local/cargo/git/checkouts/zenoh-9c599d5ef3e0480e/2215c6b/zenoh/src/api/builders/close.rs:90:17:Close when thread-local storage is unavailable (typically in atexit()) does not work for this Rust 1.85..1.85.1, see https://github.com/rust-lang/rust/issues/138696note: run with RUST_BACKTRACE=1 environment variable to display a backtraceAborted

This does not occur on x86_64 Ubuntu with the same code and Ansible automation.
The panic occurs after some runtime, not immediately, and appears to be triggered during Zenoh resource cleanup (likely at program exit).
My code does not interact with thread-local storage directly, and the panic occurs even with minimal Zenoh usage.
All Zenoh and Rust artifacts were built from scratch on a clean system.

To reproduce

On a Raspberry Pi (aarch64) with a clean OS install, install Rust 1.91.1 and the latest Zenoh from source.
Build and run a minimal Zenoh C++ application (or the official Zenoh C++ example) that:
Declares a publisher and subscriber
Publishes and receives a few messages
Exits normally after a short time
Observe the program output and note the panic during shutdown.

Expected behavior:
Program should exit cleanly with no panic.

Actual behavior:
Program panics during shutdown with the message about thread-local storage and Rust 1.85, even though Rust 1.91.1 is used.

[DEBUG] create Zenoh
[DEBUG] Session created
[DEBUG] pause

thread panicked at /usr/local/cargo/git/checkouts/zenoh-9c599d5ef3e0480e/2215c6b/zenoh/src/api/builders/close.rs:90:17:
Close when thread-local storage is unavailable (typically in atexit()) does not work for this Rust 1.85..1.85.1, see rust-lang/rust#138696
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Aborted

Additional notes:

This issue does not occur on x86_64 with the same code and environment.
All build artifacts and caches were removed before building.
The panic message appears to be a false positive or platform-specific bug in Zenoh or its dependencies.
Let me know if you need any more details or logs!

#include <zenoh.hxx>
#include <thread>
#include <chrono>

class ZenohSessionManager {
public:
    static std::shared_ptr<zenoh::Session> get_session() {
        static std::shared_ptr<zenoh::Session> session =
            std::make_shared<zenoh::Session>(zenoh::Session::open(zenoh::Config::create_default()));
            std::cout << "[DEBUG] Session created " << std::endl;
        return session;
    }
};

class ZenohChannel {
private:
    std::string topic_name;
    std::shared_ptr<zenoh::Session> session;
    zenoh::Publisher pub;
    zenoh::Subscriber<void> sub;

public:
    ZenohChannel(const std::string& topic)
        : topic_name(topic),
        session(ZenohSessionManager::get_session()),
        pub(session->declare_publisher(zenoh::KeyExpr(topic_name))),
        sub(session->declare_subscriber(
            zenoh::KeyExpr(topic_name),
            [this](const zenoh::Sample &sample) {
                std::cout << "[DEBUG] Subsriber " << std::endl;
            },
            zenoh::closures::none
        ))
    {}

    void publish(std::string msg) {
        std::cout << "[DEBUG] Publisher " << std::endl;
    }

};

int main() {
    std::cout << "[DEBUG] create Zenoh " << std::endl;
    ZenohChannel z_channel("test/topic");
    std::cout << "[DEBUG] pause " << std::endl;
    std::this_thread::sleep_for(std::chrono::seconds(5)); // Wait 5 seconds

    return 0;
}```

### System info

Platform: Raspberry Pi 4, aarch64 (ARM64)
OS: [Debian GNU/Linux 12 (bookworm)]
Rust: 1.91.1 (ed61e7d7e 2025-11-07)
Zenoh: [latest branch main]
C++: clang 14.0.6 (also tested with newer versions)
No custom patches or modifications

[gftrobots]

I removed the session manager and made the zenoh channel a singleton itself.
The issue is caused by the singleton and there is an issue deep inside zenoh / rust.
Can this be fixed?

#include <zenoh.hxx>
#include <thread>
#include <chrono>

class ZenohChannel {
private:
    static std::shared_ptr<zenoh::Session> get_shared_session() {
        static std::shared_ptr<zenoh::Session> session =
            std::make_shared<zenoh::Session>(zenoh::Session::open(zenoh::Config::create_default()));
        return session;
    }
    std::string topic_name;
    std::shared_ptr<zenoh::Session> session;
    zenoh::Publisher pub;
    zenoh::Subscriber<void> sub;

public:
    ZenohChannel(const std::string& topic)
        : topic_name(topic),
        session(get_shared_session()),
        pub(session->declare_publisher(zenoh::KeyExpr(topic_name))),
        sub(session->declare_subscriber(
            zenoh::KeyExpr(topic_name),
            [this](const zenoh::Sample &sample) {
                std::cout << "[DEBUG] Subsriber: " << sample.get_payload().as_string() << std::endl;
            },
            zenoh::closures::none
        ))
    {}

    void publish(std::string msg) {
        std::cout << "[DEBUG] Publisher: " << msg << std::endl;
        pub.put(msg);
    }

};

int main() {

    std::cout << "[DEBUG] create Zenoh " << std::endl;
    ZenohChannel z_channel("test/topic");

    auto start = std::chrono::steady_clock::now();
    while (std::chrono::steady_clock::now() - start < std::chrono::seconds(10)) {
        z_channel.publish("hello");
    }

    std::cout << "[DEBUG] done " << std::endl;

    return 0;
}

[gftrobots]

I have investigated the issue and found the root cause: assigning a zenoh::Session to a static or global variable (pointer or object) causes the program to panic with a thread-local storage error after a few seconds of normal operation. This prevents safe use of globally shared sessions in C++ applications on ARM HW platforms. Notably, the issue does not occur on x86 hardware platforms.