[asterisk-bugs] [Asterisk 0012508]: handle_response_peerpoke floods asterisk cli with notices, cli crashes

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12508 
====================================================================== 
Reported By:                kactus
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12508
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.0 
SVN Revision (number only!): 114601 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             04-23-2008 22:35 CDT
Last Modified:              06-30-2008 23:35 CDT
====================================================================== 
Summary:                    handle_response_peerpoke floods asterisk cli with
notices, cli crashes
Description: 
Since upgrading asterisk to svn later than 1.6 beta 8 cli is flooded with 

NOTICE[7435]: chan_sip.c:16045 handle_response_peerpoke: Peer 'PEERNAME'
is now Reachable. (71ms / 2000ms)

several times a second. Did not happen with svn releases around the time
of beta 6 and 7 aprox around april 17 (sorry didn't keep the old revision
numbers) or earlier revisions. 

disconnecting phone or rebooting causes:
[Apr 24 11:22:31] NOTICE[7435]: chan_sip.c:19841 sip_poke_noanswer: Peer
'DRA-997896-0043' is now UNREACHABLE!

being spammed in the same fashion.

after running it for a while we end up seeing

[root at voip02 asterisk]# /usr/sbin/safe_asterisk: line 117:  7427
Segmentation fault      (core dumped) nice -n $PRIORITY
${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} >&/dev/${TTY} </dev/${TTY}
Asterisk ended with exit status 139
Asterisk exited on signal 11.
Automatically restarting Asterisk.
mpg123: no process killed

I'll need to recompile for "don't optimise" so I haven't attached a core
debug, let me know if you need it. I will attached the sip info with sip
debug as well.
====================================================================== 

---------------------------------------------------------------------- 
 kactus - 06-30-08 23:35  
---------------------------------------------------------------------- 
Hi guys, lets see what you can make of this.

Ran the pbx with version 1.4.21 under valgrind using the standard commands
as in your valgrind doc. I then connected a SPA962 and started recieving
the same behaviour as before. I then joined the Snom 190 just so that it
might die a bit quicker. Examples of the behavior exprerienced is in "sip
behaviour 1.4.txt" 

It ran for a considerable length of time, much slower than without
valgrind, until it eventually stopped spamming the console. I was able to
connect via asterisk -r from another session but phones where unable to
connect at that point. CPU usage was maxed out and memory was quite high. I
turned on sip debug and 10 seconds of the out put are included above in "10
seconds of sip debug.txt"

It did not crash hard, mearly stopped accepting any connections from
phones, so I killed the process using -11 to force a core dump. I ended up
with a valgrind.core but could not backtrace it due to getting this error:

This GDB was configured as
"x86_64-redhat-linux-gnu"..."/etc/asterisk/debugging/valgrind.txt.core.2821":
not in executable format: File format not recognized

(gdb) bt
No stack.

I've included the valgrind.txt as "valgrind - 1.4.txt" but did not upload
the malloc as it was an empty file.

It took about 4 hours to get to this state (unresponsive) under valgrind.

Please let me know what information of debugging you need.

I tested asterisk 1.6 beta9 under this environment to confirm that xen was
not causing any issues.

All the best 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-30-08 23:35  kactus         Note Added: 0089452                          
======================================================================