[Home]

Summary:ASTERISK-15056: Asterisk core-dumps if used as loadgenerator using callfiles
Reporter:Thomas Baumann (bt047265)Labels:
Date Opened:2009-10-29 17:48:21Date Closed:2009-11-13 14:59:44.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_timing_pthread
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk_lasttest.txt
( 1) gdb.txt
Description:A perl script is used to generate asterisk call files. 1500 "Asterisk Clients" are connected to another SIP-Softswitch.

A calls B and on both ends RTP will be played. Call files are written with "modify" time, this allows to limit the calls per second.

./load_generator.pl -f numbers.txt -cmax 250 -cps 10

Asterisk restarts with about 300 active calls:

/usr/sbin/safe_asterisk: line 146: 15582 Segmentation fault      (core dumped) nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} >/dev/${TTY} 2>&1 </dev/${TTY}
Asterisk ended with exit status 139
Asterisk exited on signal EXITSTATUS-128.

System and Version:

1. SVN revision number ("svn info")
 
Connected to Asterisk SVN-branch-1.6.1-r226386 currently running on b-lab-asterisk-load (pid = 17093)
   
2. Platform (O/S)
 
Linux b-lab-asterisk-load 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux


Attached Symptoms:

- CLI log
- gdb backtrace

****** ADDITIONAL INFORMATION ******

The following sip.conf is used:

register => 405550002@10.10.10.1:405550002:405550002@10.10.10.2:5060/405550002
...
register => 405551502@10.10.10.1:405551502:405551502@10.10.10.2:5060/405551502

[0405550002]
type=peer
outboundproxy=10.10.10.2
fromdomain=10.10.10.1
host=10.10.10.2
fromuser=405550002
username=405550002
secret=405550002
context=incoming
dtmfmode=inband
disallow=all
allow=ulaw
allow=alaw
allow=gsm
allow=g729
insecure=port,invite
...
[0405551502]
type=peer
outboundproxy=10.10.10.2
fromdomain=10.10.10.1
host=10.10.10.2
fromuser=405551502
username=405551502
secret=405551502
context=incoming
dtmfmode=inband
disallow=all
allow=ulaw
allow=alaw
allow=gsm
allow=g729
insecure=port,invite

Extension conf:

[incoming]
; 1 minute call duration
exten => _XXXXXXXX[0-4],1,Answer()
exten => _XXXXXXXX[0-4],n,NoOp("0-4")
exten => _XXXXXXXX[0-4],n,Wait(1)
exten => _XXXXXXXX[0-4],n,Playback(demo-instruct)
exten => _XXXXXXXX[0-4],n,Hangup()
;
; 2 minute call duration
exten => _XXXXXXXX[5-9],1,Answer()
exten => _XXXXXXXX[5-9],n,NoOp("5-9")
exten => _XXXXXXXX[5-9],n,Wait(1)
exten => _XXXXXXXX[5-9],n,Playback(demo-instruct)
exten => _XXXXXXXX[5-9],n,Playback(demo-instruct)
exten => _XXXXXXXX[5-9],n,Hangup()

[answer]
exten => 10,1,Answer()
exten => 10,n,Wait(1)
exten => 10,n,Playback(demo-instruct)
exten => 10,n,Playback(demo-instruct)
exten => 10,n,Playback(demo-instruct)
exten => 10,n,Wait(5)
exten => 10,n,Hangup()

Example Call File:

Channel:  SIP/0405551502/0405551365
WaitTime: 5
Context: answer
Extension: 10
Archive: yes
Comments:By: Thomas Baumann (bt047265) 2009-11-07 18:00:45.000-0600

Maybe it is helpfull, with Version 1.4.26.3 this problem does not exist.
By: Tilghman Lesher (tilghman) 2009-11-11 14:51:50.000-0600

It doesn't seem to be an Asterisk issue; rather, the "@plt" string in gdb indicates that the PLT in the linker is at fault.  Quite simply, the linker cannot find the ao2_unlock function.  This is rather strange because the PLT is used for lazy linking of symbols, which is not the linking type requested for ao2_unlock() in our Makefile and may point to other problems.

You need to report this error to your distribution vendor, as a problem in their linker tools.