Reopen if still an issue.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1948#issuecomment-493070329___
Kamailio (SER) - Development
Closed #1948.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1948#event-2346469628___
Kamailio (SER) - Development Mailing List
Thanks -- have applied it to 5.2.2 and will be soak testing over the next
couple of days.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@gormania - indeed, there was an issue with incrementing/decrementing that
counter. Can you test with latest master (or the patch referenced above)? If
all ok, then it will be backported.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
Yes we are using KEMI (python bindings) and use the htable module. It appears
that `pv_cache_drop` is especially crafted for dropping `$sht` variables for
this use case. But there's no obvious path to it ever being called.
--
You are receiving this because you are subscribed to this thread.
AFAIK pv_cache works that way. We put the pv vars that we use in the config in
private mem and it should not be cleaned, ever. There's no leak.
Are you using different pv names for every SIP message processing? Are you
using KEMI?
--
You are receiving this because you are subscribed to this
### Description
We are experiencing sticky OOM state after an extended period (several days).
`kamcmd` inspection of mem use shows memory consumed (leaked) via
`pv_cache_add(347)` calls.
Inspection of that function suggests nothing can ever be dropped from the cache
-- rendering it leaky.
