PipeWire backend: connect the filter only once its port exists (supersedes #249)

[jcelerier]

Builds on #249 by @ryanatseolaudio (his commit is kept as the first commit of this branch) and fixes the ordering that made the guard necessary.

Problem

The guard in #249 is correct as far as it goes, but two things remained:

1. Debug builds still abort. The midi_in variants kept assert(this->flt); assert(this->port.valid()); above the new guard, so with asserts enabled the abort at midi_in.hpp:95 was unchanged.
2. The root cause is an ordering bug, not a race. The backends connected the filter in the constructor and added the port in open_port(). The node carries node.always-process, so the daemon schedules it as soon as it is exported, ports or not (context.c makes an always-process node runnable on its own), and impl_node_process calls the user callback unconditionally. A midi_in/midi_out constructed and not opened immediately runs process() against a null token within milliseconds, and pw_filter_dequeue_buffer(nullptr) dereferences an invalid pointer (SPA_CONTAINER_OF on null). Same code path in PipeWire 0.3.48, 1.0.5 and 1.6.8.
3. The close path was a use-after-free window, not just a null token. pw_filter_remove_port frees the port on the caller's thread with no data-loop synchronization while the filter stays connected, so a process() in flight can check port.valid() and then dequeue from freed memory. The guard only narrows that window.

Fix

• create_filter() no longer connects. A new start_filter() step runs after create_local_port() (and after set_port_buffer() for outputs), connects the filter and waits for the node id as before. Ports and their params therefore exist before pw_filter_connect, the same order PipeWire's own examples use.
• close_port() and the destructor go through release_filter(): filter::stop() disconnects, which unprepares the node on the data loop synchronously (pw_impl_node_destroy → do_node_unprepare), then pw_filter_destroy frees the port itself. The next open_port() creates a fresh filter. pw_filter_remove_port is no longer called on a live filter.
• The asserts above the guard are removed; the guard stays as defence in depth with an updated comment.

Verification

Header-only test program against PipeWire 1.6.8, run with asserts on and with NDEBUG:

scenario	before	#249 alone	this PR
midi_in constructed, never opened, 3 s	segfault / assert abort	ok (NDEBUG) / assert abort	ok
midi_out constructed, never opened, 3 s	segfault	ok	ok
200 open_virtual_port/close_port cycles (in)	crash ~1 run in 4	ok	ok
200 open/close cycles (out)	ok	ok	ok
100 construct/open/destroy cycles	ok	ok	ok
6 immediate open/close cycles, 0 ms apart	–	ok	ok

The pipewire examples and tests/integration/pipewire_context_subscriptions.cpp still compile.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EuaGAzPuXJNAUNkNFPDXro

[jcelerier]

Added tests/integration/pipewire_midi_port_lifecycle_test, since none of the existing pipewire tests touch the MIDI backends. It idles an unopened midi_in/midi_out for 500 ms, runs 100 open/close cycles on both and 30 construct/open/destroy cycles, then checks the shared context is still connected.

• master before PipeWire backend: process() can run before the local port exists — null port token, segfault in release builds #249: segfault in the idle step
• PipeWire backend: process() can run before the local port exists — null port token, segfault in release builds #249 alone, asserts enabled: abort on the assert above the guard
• this branch: passes with and without NDEBUG

Full suite on this branch: 17/17 pass (the five pipewire_context_* tests run for real against the local daemon, not skipped).

[jcelerier]

Also verified on a second machine: Ubuntu 24.04.4 LTS, libpipewire 1.0.7 (the reporter's distro, one point release ahead of 1.0.5), gcc 13.3, running against the user's live daemon. LIBREMIDI_HAS_PIPEWIRE_UMP is not available there, so only the MIDI 1.0 pipewire backends are exercised.

• Debug (asserts on): 17/17 tests pass; the five pipewire_context_* tests ran for real (not skipped); pipewire_midi_port_lifecycle_test passed 3/3.
• Release: pipewire_midi_port_lifecycle_test passed 3/3.

[jcelerier]

@ryanatseolaudio if you have time to check this PR? it should solve the issues across all cases.

[ryanatseolaudio]

@jcelerier Bug appears to be squashed, thanks!

[ryanatseolaudio]

lgmt

[jcelerier]

great thanks !