[asterisk-dev] Asterisk lock-ups tracking w/o DEBUG_THREADS

[Kirill Katsnelson]

We have been experiencing lock-ups that Russel identified as happening 
in timerfd code. A thread waiting on timer stalled with channel lock 
held, and everything else chain-locked on it. He suggested going dahdi 
timing, so I did. We do not have any dahdi hardware (SIP only).

Now as load has increased on that machine we also getting freezes. I got 
2 core dumps by killing the locked process, but do not have lock traces, 
as the asterisk was compiled without DEBUG_THREADS (DONT_OPTIMIZE is 
still enabled).

Question 1: how useful is the core dump of a locked asterisk without the 
lock info? I am looking at the cores but they do not seem very 
informative to me. Should I add them to the open issue, or is that 
useless? To be clear, I am not even sure if the new freezes are related.

Question 2 is trickier. When compiled with DEBUG_THREADS, previously I 
had Asterisk peaking at about 90% CPU on that hardware with "old" load. 
Now with increased load I am afraid CPU will not hold if I enable the 
option. Are there any hacks that would get enough of a trace but without 
the full overhead of DEBUG_THREADS?

  -kkm