]> git.ipfire.org Git - thirdparty/asterisk.git/commit
manager.c: Invalid ref-counting when purging events
authorNathan Monfils <nathanmonfils@gmail.com>
Mon, 5 May 2025 08:47:43 +0000 (10:47 +0200)
committerNathan Monfils <nathanmonfils@gmail.com>
Tue, 13 May 2025 16:52:07 +0000 (16:52 +0000)
commitfdf66d7654dd2cffb046e7e6adcd79c07b711c28
tree31458377b81225c64da05f568f3b32ca0a822245
parent00628134b032f441c6621901d900d94d1c47ed58
manager.c: Invalid ref-counting when purging events

We have a use-case where we generate a *lot* of events on the AMI, and
then when doing `manager show eventq` we would see some events which
would linger for hours or days in there. Obviously something was leaking.
Testing allowed us to track down this logic bug in the ref-counting on
the event purge.

Reproducing the bug was not super trivial, we managed to do it in a
production-like load testing environment with multiple AMI consumers.

The race condition itself:

1. something allocates and links `session`
2. `purge_sessions` iterates over that `session` (takes ref)
3. `purge_session` correctly de-referencess that session
4. `purge_session` re-evaluates the while() loop, taking a reference
5. `purge_session` exits (`n_max > 0` is false)
6. whatever allocated the `session` deallocates it, but a reference is
   now lost since we exited the `while` loop before de-referencing.
7. since the destructor is never called, the session->last_ev->usecount
   is never decremented, leading to events lingering in the queue

The impact of this bug does not seem major. The events are small and do
not seem, from our testing, to be causing meaningful additional CPU
usage. Mainly we wanted to fix this issue because we are internally
adding prometheus metrics to the eventq and those leaked events were
causing the metrics to show garbage data.
main/manager.c