[Home]

Summary:ASTERISK-06835: Crash/hang on uclibc based systems with call files
Reporter:Sune Kloppenborg Jeppesen (jaervosz)Labels:
Date Opened:2006-04-24 07:37:22Date Closed:2006-05-30 09:25:04
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-debug
( 1) asterisk-debug1
( 2) asterisk-debug2
Description:At work were going to use Asterisk for a kind of personal alarm. To that end we employ call files to generate a lot of calls when the alarm is triggered. Unfortunately this also triggers an Asterisk bug when running on uclibc (at least Ive been unable to recreate the problem with 16k call files on a glibc system). I've recreated the problem on 1.2.1, 1.2.6 and 1.2.7.1 so I guess all 1.2.x versions are affected.

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

I use the following simple dialplan to recreate the issue:

[crash_out]
exten => _XXXXXXXX,1,Set(t=${EXTEN})

And then the following script to generate call files:

#!/bin/bash

tmpdir=`mktemp -d -t alarm.XXXXXX`
astspooldir="/var/spool/asterisk/outgoing/"
numbers=""
i="1000"

while [ $i -lt $end ]
do
       numbers=`echo "$numbers ${i}"`
       i=$[$i+1]
done

for nr in $numbers; do
               tmpfile=`mktemp -p $tmpdir -t call.XXXXXX`
               echo Channel: Local/7777$nr@crash_out > $tmpfile
               echo Extension: s  >> $tmpfile
done

chown -R asterisk:asterisk $tmpdir/
mv $tmpdir/* $astspooldir/
rm -rf $tmpdir

When you set ulimit -s unlimited and ulimit -n 10000 Asterisk does not coredump any longer, only hangs.
Comments:By: Serge Vecher (serge-v) 2006-05-03 10:07:38

jaervosz, let's try a couple of things:
1) See if a patch made by jupiter in http://bugs.digium.com/view.php?id=6570 will help you. They also had problems with generated call files.
2) Download the latest 1.2 branch, which contains a fix from bug ASTERISK-6882 and which may also have an impact on this. Build with 'make dont-optimize' and post un updated bt if the problem still persists.

Let us know how it turns out.

Thanks!
By: Sune Kloppenborg Jeppesen (jaervosz) 2006-05-03 16:56:27

vechers, thanks for the answer.

1) applying the patch from bug ASTERISK-6395 does not fix the issue.
2) applying the patches form bugs ASTERISK-6395 and ASTERISK-7756 does not fix the issue.

I didn't explicitly 'enable make dont-optimize', let me know if it's a problem and I'll rebuild it by hand, it's getting late here now.

Uploaded asterisk-debug1 with updated backtraces from 2).
By: Serge Vecher (serge-v) 2006-05-04 08:53:41

jaervosz, backtraces only make sense when asterisk is built with make dont-optimize option. Please rebuild and upload those crashlogs. Thanks.
By: Sune Kloppenborg Jeppesen (jaervosz) 2006-05-07 13:54:13

Vechers, thanks for the answer again.

New backtrace with the dont-optimize option attached.
By: Serge Vecher (serge-v) 2006-05-22 12:57:05

jaervosz: as per joshnet, the line numbers do not match the tarball source. Can you please redo a backtrace (non-optimized) from unmodified 1.2.7.1 sources or better yet latest 1.2 branch code (rev > 29000), also unmodified.

Thank you.
By: Serge Vecher (serge-v) 2006-05-30 09:25:04

Please feel free to reopen when you have requested information available. Thanks.