net/asterisk13: memory leak under 12-CURRENT?

[O. Hartmann]

On Wed, 27 Sep 2017 12:23:20 +0200
Guido Falsi <madpilot at FreeBSD.org> wrote:

> On 09/27/2017 11:27, O. Hartmann wrote:
> > On Wed, 27 Sep 2017 09:05:42 +0200
> > Guido Falsi <madpilot at FreeBSD.org> wrote:  
> >> But while asterisk is running does the memory usage increase unbounded
> >> till filling all available memory or does it stabilize at some point?  
> > 
> > As far as I could observe, a three day test run of the
> > router/firewall/asterisk box drained around 500 MB of memory: starting at
> > boot time with ~3700 MB, asterisk leaves the box with ~3640 MB after bein
> > started and after three days the system reached ~3150 MB. Stopping asterisk
> > gave back some memory, so ~3300 MB then was for days the final result - not
> > recovering anything further. I use TEMPFS, if it matters, but I
> > checked /tmp and /var/, there were no remnant files so far. TMPVAR is only
> > allowed to have 256 MB. 
> 
> These numbers really don't tell us anything. The system has anyway been
> running for days, depending on configuration daemons like cron and ntp
> are running and performing tasks, things are being cached and so on, so
> that difference after three days could be perfectly normal overhead.

I think they do, but not in a scientific way.

The system in question has to do always the same task and is running for months
with never dropping below a certain memory boundary.

Then, when asterisk started/stopped/started, memory begins to fade away and is
never getting back to "free", even with asterisk off for days, twoo weeks. Does
this really tell me nothing?

> 
> You need to investigate the amount of memory allocated to asterisk with
> ps and top and check if that stabilizes. A few days, at most a week
> would be enough. After that, if it's not stabilizing you can start
> thinking on a leak, but still can't assume where the leak is happening.
> 
> 
> > Can't say whether it is stabilising or not - I think the runtime is too
> > short. I'll check first to disable some modules in the first place and then
> > try to perform a test with several days of asterisk enabled.
> >   
> 
> Whatever you prefer, but trying a few days uptime with all modules
> enabled is zero cost and east to do. Also you started this report with
> THIS configuration, changing configuration would prevent from comparing
> results. Let's test one thing at a time.
> 

I will.
Now as we have a indication that there is porbably something, I'll go for
deeper investiagtions with a static config.