[asterisk-users] Disappearing B-Channels

[Tilghman Lesher]

On Monday 11 February 2008 13:57, Ben Willcox wrote:
> Mark Greene wrote:
> > I could do that. The only issue is that I don't understand why others
> > with my setup have not had to do the same. What's unique about my TDMoE
> > setup that makes it intolerant to channel restarts? I did everything by
> > the book.
>
> We had a similar problem, and although your symptoms are not identical,
> we had a massive ongoing problem with the reliability of our ISDN
> channels, where they would randomly stop working until eventually we
> could no longer make any outgoing or incoming calls via our PRI line. A
> restart of asterisk was needed to get it working again.
>
> We finally discovered that the problem was our use of cacti, monitoring
> channel usage via the manager interface. We were hitting the manager
> interface with 4 connects, queries and disonnects per minute, and over
> the course of a day, asterisk would start dropping calls and other
> strange behaviour. I guess there is a memory leak or similar with the
> asterisk manager interface.
>
> Perhaps not your particular problem, but thought I'd throw it in there
> anyway as you never know...

We had a problem with the manager interface like this that is now fixed.
The issue was that if a thread's lifetime was less than one complete context
switch, then the master manager thread would write information to memory
that had already been deallocated (and possibly allocated to something
else).  We fixed this by adding a usleep(1) to the end of the manager thread,
which ensures that each manager thread will last at least past the first
context switch, which is enough to prevent this memory corruption.  Any
thread that lasts for shorter than a complete context switch (which is 1/10th
of a second since, well, forever) or whenever a thread yields the processor,
whichever comes first, could also cause similar memory corruption.

-- 
Tilghman