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. -------------- next part -------------- A non-text attachment was scrubbed... Name: op_catch_rep_finalise.patch Type: text/x-patch Size: 641 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20180705/cc85e256/attachment.bin>
