[Home]

Summary:ASTERISK-16017: [patch] it crashes handling dtmf relay
Reporter:Private Name (falves11)Labels:
Date Opened:2010-04-27 06:27:03Date Closed:2010-05-19 09:47:15
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk_dtmf_crash.txt
( 1) issue_17248.diff
Description:I am uploading the trace.
Comments:By: Paul Belanger (pabelanger) 2010-04-27 08:51:59

Again, we need more information.  How do you reproduce the issue.
---
Thank you for taking the time to report this bug and helping to make Asterisk better.

Unfortunately, we cannot work on this bug because your description did not include enough information.

You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines.

We\'d be grateful if you would then provide a more complete description of the problem.

At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf).

Thanks!
By: Private Name (falves11) 2010-04-27 09:09:07

I have an application that process millions of calls per day, always the same process. I see that it crashed and since it is compiled with debug information, I do a gdb asterisk core.xxx and take bt, and bt full. The trace should explain the issue. I have absolutely nothing more to add except show you my dialplan, but that will not help much. The calls are 100% SIP2SIP. My box and my dialplan are both open for inspection.
I wonder why we cannot get any useful information from traces alone. I cannot run my system with debug level, for in 150 open calls the system will be overwhelmed. Moreover, it crashes randomly.
I need to stay in 1.6 since it offers Sip Timers, and if nobody uses it and everybody hides in 1.4, it will never be stable. Please help me understand what can I do that does not kill my business.
By: Private Name (falves11) 2010-04-27 10:53:09

Please close the case. I will go back to 1.4. I am unable to reproduce the issue or provide any additional information, plus my dialplan is not relevant since we ignore where it happened. I think it blew up when a somebody pressed "1"
By: David Woolley (davidw) 2010-04-27 11:16:51

I'm sorry, but this report was sufficient to identify a clear bug in only about 5 minutes.  I realise that people often don't provide enough information but sometimes it is unrealistic to provide the officially required information, and particular, for some of those cases, especially those involving crashes, the actual information can still be enough to find and fix a bug.

In this case, the code skeleton is:

struct ast_frame *f = NULL;

.....

} else if ((rtp->resp == resp) && !power) {
f = create_dtmf_frame(rtp, AST_FRAME_DTMF_END);
f->samples = rtp->dtmfsamples * (rtp_get_rate(f->subclass) / 1000);
rtp->resp = 0;
} else if (rtp->resp == resp)
rtp->dtmfsamples += 20 * (rtp_get_rate(f->subclass) / 1000);


There is no looping, so it is trivial to demonstrate that f must be null on the final else, and therefore that, either that else clause is unreachable, or it will always crash, both cases being bugs.
By: Private Name (falves11) 2010-04-27 11:30:41

Fantastic. This proves the point. The trace must be enough to identify the issue.
Could you, dear David, take a look at the other bugs that I filed with a trace in all cases?
https://issues.asterisk.org/view.php?id=17249
https://issues.asterisk.org/view.php?id=17246
By: Paul Belanger (pabelanger) 2010-04-27 11:33:41

I'm not disputing there is a bug in the code, however in an effort to triage issues for marshals and developers more information is always better then less.  It also helps to describe how to reproduce the issue, for people not strong enough to debug a backtrace.
By: Leif Madsen (lmadsen) 2010-04-27 12:08:59

Removed useless comment.
By: Private Name (falves11) 2010-04-27 17:59:22

I wonder if this bug also affects 1.4.
By: Private Name (falves11) 2010-04-28 20:40:35

Is there a chance to get patch soon? it keeps crashing in this function and in rtp-timeout.
By: Paul Belanger (pabelanger) 2010-04-29 09:11:53

I'm sure you're aware of this but, your issue is in queue, please be patient and we will get to it as time permits and developer resources become available.
By: Leif Madsen (lmadsen) 2010-04-30 13:46:43

The only way to guarantee an issue gets resolved in time matter is to resolve the issue yourself (and ideally provide the patch here) or to find someone (perhaps a consultant) who is able to resolve the issue for you.
By: David Vossel (dvossel) 2010-05-11 16:26:28

I posted a patch, please test it and let me know if it resolves the issue.
By: Leif Madsen (lmadsen) 2010-05-19 09:23:56

Please test this per dvossel.
By: Digium Subversion (svnbot) 2010-05-19 09:38:02

Repository: asterisk
Revision: 264114

U   trunk/res/res_rtp_asterisk.c

------------------------------------------------------------------------
r264114 | dvossel | 2010-05-19 09:38:02 -0500 (Wed, 19 May 2010) | 13 lines

fixes crash during dtmf

During the processing of Cisco dtmf the dtmf samples were
not being calculated correctly.  In an attempt to determine
what sample rate was being used, a NULL frame was processed
which caused a crash.  This patch resolves this.

(closes issue ASTERISK-16017)
Reported by: falves11
Patches:
     issue_17248.diff uploaded by dvossel (license 671)


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=264114
By: Digium Subversion (svnbot) 2010-05-19 09:47:14

Repository: asterisk
Revision: 264115

_U  branches/1.6.2/
U   branches/1.6.2/main/rtp.c

------------------------------------------------------------------------
r264115 | dvossel | 2010-05-19 09:47:13 -0500 (Wed, 19 May 2010) | 19 lines

Merged revisions 264114 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r264114 | dvossel | 2010-05-19 09:38:02 -0500 (Wed, 19 May 2010) | 13 lines
 
 fixes crash during dtmf
 
 During the processing of Cisco dtmf the dtmf samples were
 not being calculated correctly.  In an attempt to determine
 what sample rate was being used, a NULL frame was processed
 which caused a crash.  This patch resolves this.
 
 (closes issue ASTERISK-16017)
 Reported by: falves11
 Patches:
       issue_17248.diff uploaded by dvossel (license 671)
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=264115