The internal operation_set_state function already returns early if the
new state is the same as the existing state. The attached patch extends
this to return early if already in a finalised (done/cancelled) state,
i.e. blocks attempts to re-finalise into a different state.
This helps avoid unlinking more than once (or crashing on ref count
assertion).
I was not certain whether an assertion would be a better alternative -
with such a crash helping highlight usage problems...
The situation that lead to this was the thought of someone stupidly
trying to pa_operation_cancel() a callback within the callback
execution itself, while designing a solution for a memory leak related
to cancellation within my Rust binding. While no-one should do such a
thing, if they did, they'd either trip up a ref count assertion, or the
operation would be unlinked twice, which would be bad. It's a simple
thing to catch and mitigate, and could prove to be a useful
bulletproofing measure for this function in general.
From ae1751da90d1dfcef7c40ee5e2061173fb781def Mon Sep 17 00:00:00 2001
From: Lyndon Brown <[email protected]>
Date: Thu, 5 Jul 2018 04:54:03 +0100
Subject: operation: avoid state change from final state
diff --git a/src/pulse/operation.c b/src/pulse/operation.c
index 61adf69b0..3f396f008 100644
--- a/src/pulse/operation.c
+++ b/src/pulse/operation.c
@@ -102,6 +102,9 @@ static void operation_set_state(pa_operation *o, pa_operation_state_t st) {
if (st == o->state)
return;
+ if ((o->state == PA_OPERATION_DONE) || (o->state == PA_OPERATION_CANCELED))
+ return;
+
pa_operation_ref(o);
o->state = st;
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
