I don’t know 
But people has asked me this a couple of times lately and my answer is always “I don’t know”. However ps can give you more information about it. In fact, this works for any application you have and you want to debug why is going crazy.
First, check which thread (Asterisk is a multi threaded application) is going crazy.
# ps -LlFm -p `pidof asterisk`
That should show you the % of CPU being used by each Asterisk thread in the column named “C”, then write down the LWP colum value for the thread you are interested on. (LWP is a light weight process number, roughly speaking, the thread id). Now that you have the thread id, you need to know what that thread is doing.
# pstack `pidof asterisk` > /tmp/asterisk.stack.txt
That will cause the asterisk process to dump the stack state to the /tmp/asterisk.stack.txt file. If you don’t have the pstack command google for it, I think in CentOS is as easy as yum install pstack.
Then open the file and search for the LWP that you just wrote down. Hopefully you will find some hints that let you know how to avoid it or at least a lot more information to post in bugs.digium.com
UPDATE:
One of the guys who asked this question later told me what he found:
Thread 10 (Thread 0×41d8f940 (LWP 3406)):
#0 0×00000033ce2ca436 in poll () from /lib64/libc.so.6
#1 0×00000000004933c0 in ast_io_wait ()
#2 0×00002aaabd9510cd in network_thread ()
#3 0×00000000004f8b2c in dummy_start ()
#4 0×00000033cee06367 in start_thread () from /lib64/libpthread.so.0
#5 0×00000033ce2d2f7d in clone () from /lib64/libc.so.6
A quick grep -rI “network_thread” in the Asterisk source code reveals this function belongs to chan_iax.c, disabling chan_iax.so in modules.conf is a good workaround to his problem, however further debugging would be needed to determine why the monitor thread is looping like that.