BambuNetwork bridge deadlocks on Apple Silicon (M1/M2/M3) — both ABI variants fail under Rosetta

Summary

On Apple Silicon (M1/M2/M3), the BambuNetwork bridge runtime never completes handshake with the macOS app. End users get a persistent "Linux bridge payload not ready" dialog (see #5) and after dismissing it the app shows "Complemento de red no detectado". The app's main thread eventually deadlocks in RpcClient::stop() while reader_loop is blocked reading the stdout pipe from the in-VM binary.

This affects the v1.0.0 release DMG (OrcaSlicer_Mac_universal_V2.4.0-dev.dmg) as well as a fresh CI rebuild from main. Binaries are byte-identical between release and CI rebuild, so it is not a build-cache stale issue.

Environment

• Hardware: Apple Silicon (M-series), arm64
• macOS: 15+ (tested on 26.5/Tahoe)
• VM stack: bundled Lima 2.1.1 + Apple Virtualization framework + Rosetta-for-Linux
• VM image: Ubuntu 25.10 (questing, glibc 2.42) — also reproduced on Ubuntu 24.04 LTS (noble, glibc 2.39) after manually rebuilding the VM
• Multiarch amd64 (libc6:amd64, libstdc++6:amd64, libgcc-s1:amd64) was installed inside the VM to satisfy Rosetta's need for /lib64/ld-linux-x86-64.so.2. Without it the binary aborts immediately with rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2.

Behavior per ABI variant

Even with multiarch installed and Rosetta able to load the binary:

pjarczak_bambu_linux_host_abi1 — SIGSEGV in Rosetta

rosetta error: could not find free space for allocation size 7fffff7b0000
exit=139 (SIGSEGV)

The allocation size 0x7fffff7b0000 (~140 TB) looks like an uninitialized/corrupted size argument — likely a Rosetta bug interacting with _GLIBCXX_USE_CXX11_ABI=1 symbols. Reproducible on both Ubuntu 24.04 LTS and 25.10.

pjarczak_bambu_linux_host_abi0 — silent read-loop, no response

Does not crash. Process state inside VM:

State: S (sleeping)
wchan: pipe_read
stack:
  pipe_read+0x40c/0x480
  vfs_read+0x318/0x348
  ksys_read+0x118/0x140
  __arm64_sys_read+0x28/0x50
fd 0 -> pipe (stdin from ssh from app)
fd 1,2 -> pipes (stdout/stderr to app)

The binary reads stdin frames but never writes a response to stdout. Confirmed both by direct test (binary, then EOF, exits 0 with empty stdout/stderr) and by the live state above where the binary sits idle in pipe_read after the app sent the bridge.handshake frame.

App-side deadlock

sample of the hung OrcaSlicer process (main thread):

main-thread
  bambu_network_get_version  (libpjarczak_bambu_networking_bridge.dylib)
    RpcClient::invoke_json("bridge.handshake", {})
      RpcClient::request_impl(...)
        RpcClient::ensure_handshake()
          RpcClient::stop()                          ← blocked

Reader thread:

std::__thread_proxy<...start_locked()::$_0>
  RpcClient::reader_loop()
    read_raw_frame(istream&, RawRpcFrame&, ...)
      std::basic_istream::read(...)
        boost::process::basic_pipebuf::underflow()
          boost::process::posix::basic_pipe::read(...)  ← blocked

ensure_handshake() apparently hit its timeout (no response from binary) and called stop(). stop() waits for reader_loop to finish; reader_loop is blocked on basic_pipe::read() waiting for bytes from a binary that is alive but never writes. Result: hard deadlock — the app shows "not responding" and macOS surfaces the spinning beachball.

Reproducer

1. Apple Silicon Mac, macOS 15+
2. Install Bambu Studio at least once so ~/Library/Application Support/BambuStudio/plugins/libbambu_networking.dylib and libBambuSource.dylib exist (release v1.0.0 won't complete its initial installer otherwise; see #5)
3. Install OrcaSlicer-bambulab OrcaSlicer_Mac_universal_V2.4.0-dev.dmg
4. Launch the app, accept the "Install Lima runtime" prompt, let it complete
5. Reopen the app → handshake hangs → "Aplicación no responde"

Investigation steps that did NOT fix it

Suggested next step

The binary needs to be debugged with symbols / gdb inside the VM to find where abi0's response path is silently dropped. My guess (from the wrapper env vars passed by the app, including PJARCZAK_EXPECTED_BAMBU_NETWORK_VERSION=02.05.02.58) is that ABI version validation against the loaded .so is failing somewhere in LinuxPluginHost::load_modules() or abi_version_matches_expected() and the early-return path doesn't emit a response frame — leaving the host alive in its main read loop without ever signaling failure.

Happy to test patches and run them through my fork's CI.

Workaround for end users on Apple Silicon today

• Use OrcaSlicer-bambulab for slicing + LAN
• Use the official Bambu Studio app for cloud printing

(Filed alongside #12 which fixes a separate macOS 15+ build issue — unrelated to this runtime issue.)