Thank you for the feedback. Ok, this would be a bit more complex change. I will
need to get some time to look into it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes, this happens. The function updating the config block and replacing some
strings of that with newly allocated values cannot free the old ones because it
does not know if a child might still use the old values. We have to wait for
all the children to release the values.
One approach could be
Thanks for the additional insight! So did I understood you correctly:
If I use Kamailio in a configuration with several children listening on
different network interfaces - if there is at least one child that does not
handle traffic the "replaced" strings are not freed?
--
You are receiving
Daniel is right, the memory should be eventually freed when ALL the child
processes update their local configuration, i.e. do at least one iteration of
their loop and call cfg_update(). Each child process updates its local cfg
pointer to the global one and travels through the pending callback
Yes, changing a cfg value e.g. every minute with this framework makes no sense.
But good comment about the update mechanism, I will play with it e.g. by
sending some SIP messages. I also looked into the code - but I am also not
deeply familiar with the code, only looked to it as well.
--
You
That could actually be part of this case -- the values are cloned by each
process to avoid sync'ing with mutexes at runtime. Each process gets the new
value when it executes cfg_update(), which is typically done when a process has
something new to do (e.g., process a new sip message). In your
I tested it with another cfg variable not related to any module (like we have
pstn.gw_ip in default cfg). The test system did not have any traffic, so i
would assume that the variable would be commited really fast. But I will have
another look to it.
--
You are receiving this because you are
I haven't really went that deep in the related code, but there are reference
counters behind those values, so they might be released when all processes get
to use the new value, which can be later in time (or never, depending on the
type of sip traffic). Overall, I am not sure if the framework
I looked today into it as well. I could reproduce it with current git master.
```
root@proxy-1:/usr/local/src/kamailio-devel# grep "^Oct 7 18:38.*
qm_status:.*alloc'd" /var/log/syslog | cut -d: -f6- | sort | uniq -c | sort -n
| grep core/cfg/cfg
1alloc'd from core:
