SIGSEGV when a synchronous BLE read is called from inside a subscription callback

[srgg]

Summary

Calling a synchronous BLE operation (blim.characteristic(svc, uuid).read()) from inside a Lua subscription callback crashes the whole process with SIGSEGV instead of raising a Lua error. The crash is not in the user script — it is memory corruption of the shared lua_State, surfacing later in golua's error path.

Environment

• blim @ 61d4c17 (embedded blim.lua), darwin/arm64
• go 1.26.1, golua v0.0.0-20250217091409-248753f411c4, srgg/go-ble v0.0.0-20251019021511-162008c817dc

Reproduction

blim.subscribe({{ service = "ff30", chars = { "ff32" } }}, function(data)
    -- any synchronous BLE op inside a notification callback:
    local char = blim.characteristic("ff50", "ff55")
    if char then char.read() end   -- <- SIGSEGV on first notification
end)

Real-world case: a UI redraw function that performs a characteristic read was invoked from a state-change notification callback. Crash is deterministic on the first firing.

Stack trace (relevant goroutine)

SIGSEGV addr=0x184, during cgo execution
goroutine 57:
  golua lua.(*State).StackTrace -> _Cfunc_lua_getinfo          <- crashes collecting traceback
  golua lua.(*State).callEx (lua.go:267)                       <- error path of the callback Call
  internal/lua.(*LuaAPI).callLuaCallback (api.go:1089)
  internal/lua.(*LuaEngine).DoWithState (lua_engine.go:208)
  internal/lua.(*LuaAPI).executeSubscription (api.go:904)
  go-ble.(*BLEConnection).runSubscription (connection_subscription.go:491)

Analysis

The lua_State is single and guarded by DoWithState. While a subscription callback runs, the state is held by the subscription goroutine. A synchronous read() issued from that context dispatches a second BLE operation whose completion/dispatch path touches the same lua_State from another goroutine. Concurrent access corrupts the Lua stack; the callback's Call then errors, and StackTrace/lua_getinfo segfaults walking the corrupted stack (addr=0x184 — small offset from NULL, i.e. a broken CallInfo). Note the existing inCallback guard protects the debug-hook/blim.sleep path, but synchronous device operations have no equivalent guard.

Expected behavior

At minimum, deterministic failure instead of process death — e.g. read()/write()/write_receive() invoked while inCallback > 0 should raise a clean Lua error:
"BLE operations are not allowed inside subscription callbacks; defer to the main loop".
(Actually supporting nested sync ops via queueing/deferral would be a separate, larger feature.)

Workaround

Perform BLE operations only from the main loop; subscription callbacks should only set flags/cache values (blim.sleep in the loop releases the state so queued callbacks run).

[srgg]

Reopening: the fix guards the wrong layer — both crashes are RaiseError-unwind corruption on LuaJIT

The raiseIfInCallback guard (6aadf85) itself crashes the process when it fires. New evidence reattributes the ORIGINAL crash too: both are the same bug, and it is not "BLE ops in callbacks" per se.

New crash (guard firing)

Entering a calibration mode → state-notify callback → blim.subscribe → guard raises:

Callback error: [string "--[[..."]:456: blim.subscribe is not allowed inside a callback; defer to the main loop

…callback unwinds, execution continues — and ~1 s later the MAIN loop dies inside lua_pcall with SIGBUS (fatal error: semasleep on Darwin signal stack, panic during panic). Goroutine dump: the only Lua-executing goroutine is the main script in DoString; all subscription fan-outs idle in select. The corruption happened earlier — at the raise.

Mechanism

golua RaiseError = panic(&LuaError{...}) — a Go panic, not a lua_error longjmp. When it fires inside a Go-registered function called by the VM, the panic propagates by abandoning the C (LuaJIT) frames: the VM's own unwinder never runs, its internal state (cframe chain, base/top) is left pointing into a dead stack region. The callback's callEx(catch=true) recovers, execution continues on the same lua_State → next VM work hits the stale frames → SIGBUS/SIGSEGV.

Terminal vs recoverable (cross-ref #4): a raise that TERMINATES the script (cancellation — the state is discarded right after) tolerates the abandoned frames. A raise that is RECOVERED with continued execution on the same state — what every callback raise is — corrupts by construction. raiseIfInCallback's "clean, recoverable Lua error" is exactly the unsafe kind.

Reattribution of the original SIGSEGV

The original crash was pcall(char.read) inside a callback → the read errored → its Go-side RaiseError → the panic flew OVER the Lua pcall (Go-backed errors are not pcall-catchable — already documented for blim.pcall) → unwind corrupted the state → callEx's error path called StackTrace → lua_getinfo SEGV on the freshly-corrupted stack. Same mechanism, different trigger. The mutex-reentrancy theory was only part of the story.

Why blim.subscribe worked from callbacks for weeks before the guard

It never releases stateMutex and never re-enters Lua; its CCCD-write round-trip completes via go-ble's connection-event path — independent of the notification fan-out blocked by the in-flight callback. Net effect was an invisible stall of the Lua world for the round-trip duration. The risks it was banned for (freeze/deadlock) are real only for path-coupled cases (see below), not for subscribe.

Fix plan

1. Lua-side raise (the actual crash fix, prerequisite for any guard). Guarded ops must not RaiseError from Go. Return a sentinel (nil, msg) and let a thin wrapper in the embedded blim.lua call error(msg) — a proper VM longjmp: recoverable, pcall-able, state stays consistent. Side benefit: operation errors (timeouts etc.) raised this way become genuinely catchable — pcall(char.read) starts working as scripts expect.

2. Narrow the guard scope. Hard ban must remain ONLY for the true-reentrancy class:

   • blim.sleep, io.read — they release stateMutex mid-callback; handing the in-flight state to another goroutine is unconditionally corrupting;
   • reading a characteristic from its own subscription callback (or any char whose response routes through the currently-blocked fan-out; CoreBluetooth also echoes reads of subscribed chars through the notification path) — real self-deadlock risk.
     Everything else is a stall, not corruption.

3. Async blim.subscribe. Subscription semantics are naturally async: register locally, fire the CCCD write asynchronously, return the cancel handle immediately, report failure via the log/error callback. Then subscribe needs no guard at all — legal from any context.

4. blim.defer(fn) — official post-callback continuation for whatever remains guarded: enqueue a Lua closure from a callback; the engine drains the queue in main context (natural drain point: entry of blim.sleep, which every script loop calls; guard against recursive drain). Scripts keep their event-driven shape:

   on_state_change = function(s) blim.defer(start_session) end

With (1)-(4), the original rule shrinks from "no BLE ops in callbacks" to "no state-mutex release and no reads through a blocked fan-out — and for those, blim.defer".