Native builds have no deinitialised guard: pulling a released audiomixer.Mixer dumps core

[bdbarnett]

Stakes. On the desktop MicroPython and the patched CircuitPython builds,
using an audio node after deinit() is undefined behaviour rather than an
error, and for audiomixer.Mixer it is a segmentation fault. A host that
tears an effect down and pulls a stale reference — a UI holding the old
node, a chain rebuilt while a render is in flight — takes the interpreter
down with it, on hardware where there is no core file to read.

Measured 2026-09-07 against AUDIOIF_PIN 2f6cbc3, one node per process
(audiocomponents/tools/compressor_deinit_use.py, written for exactly this
because a battery that walked all six killed the interpreter):

$ .venv/bin/python tools/compressor_deinit_use.py 3
node 3 Dynamics  RuntimeError: Object has been deinitialized and can no longer be used

$ cmods/bin/micropython ... tools/compressor_deinit_use.py 3
node 3 Dynamics  pulled 1024 bytes

$ cmods/bin/micropython ... tools/compressor_deinit_use.py 5
node 5 Mixer     (SIGSEGV, core dumped)

$ cmods/bin/circuitpython-effects ... tools/compressor_deinit_use.py 5
node 5 Mixer     (SIGSEGV, core dumped)

Indices 1–4 (audioroute.SplitterTap ×2, audiodynamics.Dynamics ×2)
render on as if nothing had happened on both native builds and return the
same bytes they would have returned before the deinit(). Index 5,
audiomixer.Mixer, crashes: its deinit frees the voice buffers and
get_buffer reads them.

The CPython target is the one that behaves: every released node raises
RuntimeError: Object has been deinitialized and can no longer be used, so
the check exists in the shim and not in the native modules.

Ask. The native builds get the same deinitialised guard the CPython
target has, on get_buffer at minimum — an exception, not a crash. The
Mixer is the urgent one because it is the only node measured to fault, but
a tap and a Dynamics returning stale audio silently is the same bug with a
quieter symptom.

Found while closing the Tier 1 deinit() row for Compressor
(audiocomponents/docs/effects/Compressor-evidence.md §2).

[bdbarnett]

Fixed in 2742489, together with #58 — the deinit and the guard had to land in one change.

The commit's Closes #58, #59, #60, #63 only closed the first: GitHub needs the keyword before each number. Closing the rest by hand.

What landed. deinit() on all thirteen node types that had none (every type audioif wrote itself, as against every type it ported from CircuitPython), and the deinitialised guard on audiosample_get_buffer / audiosample_reset_buffer — the funnel every pull and rewind in the palette passes through, whoever called it.

The crash surface was ten node types, not one. audiosample_mark_deinit() sets channel_count = 0 and a node's get_buffer divides by the channel count, so on the pre-change build pulling a released node dumped core for ten of the thirteen types that already had deinit():

node          before                  after
Mixer         SIGFPE  (core dumped)   raises
Chorus        SIGFPE  (core dumped)   raises
Echo          SIGFPE  (core dumped)   raises
MultiTapDelay SIGFPE  (core dumped)   raises
PitchShift    SIGFPE  (core dumped)   raises
Filter        SIGFPE  (core dumped)   raises
Distortion    SIGFPE  (core dumped)   raises
Phaser        SIGFPE  (core dumped)   raises
Freeverb      SIGFPE  (core dumped)   raises
SpeedChanger  SIGSEGV (core dumped)   raises
RawSample     returned stale audio    raises
Synthesizer   returned stale audio    raises

That is why the two halves could not be split: having deinit() without the guard was strictly more dangerous than having neither, and adding the twelve missing deinit()s on their own would have turned twelve safe types into twelve core dumps.

Gate. tests/parity/deinit_surface_probe.py, over all 25 node types, running unchanged on all three targets. --fault skips the deinit() call and must exit nonzero; CI runs the fault first and fails if it passes. The native half runs in clean-build.yml on a real MicroPython build.

No rendered bytes move: all 23 DSP probes byte-identical on MicroPython before and after.

[bdbarnett]

Correcting the record, and a finding: the guard is MicroPython-only by construction.

This was fixed by putting the deinitialised guard in audiosample_get_buffer / audiosample_reset_buffer — audioif's src/audiocore/__init__.c, which is the MicroPython binding. The patched CircuitPython build compiles its own upstream shared-module/audiocore/__init__.c, which has no such guard, so the fix does not reach that target at all. Measured on the CircuitPython build:

  audiomixer.Mixer can still be pulled after deinit()
  audiomixer.Mixer can still be rewound after deinit()
  audiospeed.Resampler can still be pulled after deinit()
  audiospeed.SpeedChanger can still be pulled after deinit()
  synthio.Synthesizer can still be pulled after deinit()

Those are upstream's own nodes, so this is not a lag in our bindings the way audioif#75 is — it is the same defect this issue reported, present in CircuitPython itself. Pulling a released node there is undefined behaviour for the same reason it was here.

That makes it an upstream report rather than a patch: it is shared-module/audiocore/__init__.c's to fix, and the fix is the same two lines. Held rather than filed, per Brad's rule of 2026-09-09 that no upstream report goes out until our own house is clean. A draft belongs in docs/upstream-reports/ beside biquad-reset.md, which is the same species and was merged upstream as CircuitPython #11268.

The MicroPython and CPython halves of this issue stand and are gated by the deinit surface probe.