[asterisk-users] How to debug this specific issue?

[Steve Davies]

On 25 August 2010 08:22, Matt Riddell <lists at venturevoip.com> wrote:
> On 25/08/10 7:20 PM, Tilghman Lesher wrote:
>>> I really thought that the canary should have sounded if Asterisk got in
>>> a loop - or maybe that only happens with high priority?
>>
>> The canary only runs in high priority mode, and it's only able to do anything
>> if high priority scheduling is the culprit.  If it's something else, like
>> memory swapping, there's nothing the canary can do to fix that.
>
> Aha, explains why I've never seen the canary die :D
>

...and yes, I was running in high priority mode - I thought I was
turning it off for testing, but looks like I left the setting in
asterisk.conf so leaving '-p' off the command line was making no
difference *sigh*

I believe the issue was actually with the devicestate thread. It was
trying to update state on a locked channel, and was trying to grab the
lock so regularly that it caused asterisk to grab lots of CPU cycles
(because of -p mode) The lock was not released because it was waiting
on a database write, which was being done by a lower priority external
process that was getting no time scheduled to it.

The database write is a local hack to record some extra call data - I
changed it to occur after the locks are released as I should have done
in the first place.

1.6.2.11 does not seem to have quite the same issue - It recovers
after the usual 200 lock attempts and gets on with life much more
happily. I cannot see any changes between 1.6.2.10 and 1.6.2.11 that
would have improved this behaviour.

Cheers,
Steve