[Home]

Summary:ASTERISK-16125: [patch] [regression] DAHDI analog FXS port segfaults after dialling 2nd DTMF digit
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2010-05-21 04:14:10Date Closed:2010-06-05 12:56:56
Priority:CriticalRegression?Yes
Status:Closed/CompleteComponents:Core/PBX
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20100524__issue17371.diff.txt
( 1) gdb_250510.txt
( 2) gdb.txt
Description:#1  0x080e12f4 in ast_dsp_process (chan=0x85e23d8, dsp=0x85e5008, af=0x85d1560) at dsp.c:1418
1418                                    memmove(&dsp->digit_state.digitlen[0], &dsp->digit_state.digitlen[1], dsp->digit_state.current_len * sizeof(dsp->digit_state.digitlen[0]));
(gdb) p  dsp->digit_state.current_len
$1 = 2
(gdb) p dsp->digit_state.digitlen[0]
$2 = 0
(gdb) p dsp->digit_state.digitlen[1]
$3 = 0
(gdb) quit


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

attached trace.

Comments:By: Alec Davis (alecdavis) 2010-05-21 04:39:36

Hum wasn't as simple as removing the 'dsp->digit_state.current_len *' from the memmove, next crash:

(gdb) frame 1
#1  0x080e12ae in ast_dsp_process (chan=0x86631b8, dsp=0x86657a0, af=0xaf204d60) at dsp.c:1416
1416                                    memmove(&dsp->digit_state.digits[0], &dsp->digit_state.digits[1], dsp->digit_state.current_digits);

(gdb) p dsp->digit_state.current_digits
$1 = 16777215
(gdb) p dsp->digit_state.digits[0]
$2 = 0 '\0'
(gdb) p dsp->digit_state.digits[1]
$3 = 0 '\0'

(gdb) p sizeof(dsp->digit_state.digits[1])
$4 = 1

By: Alec Davis (alecdavis) 2010-05-21 04:54:04

<b>svn merge -c -264204 .</b>
reverts it for the mean time with trunk

<b>svn merge -c -264205 .</b>
if you're running 1.6.2 svn

thought I was going crazy, trunk and 1.6.2 both had same problem.



By: Alec Davis (alecdavis) 2010-05-24 04:58:05

Original reported system was on a TDM800P with VPMADT32.

Since verified fault on alternate system with TDM400P and 2 FXS modules.

repeatabilty:
 pick up analog phone connected to an FXS port on the TDM800 or TDM400
 dial any 2 digits
 segfault



By: Alec Davis (alecdavis) 2010-05-25 02:48:15

applied diff.

Segfaults still after dialling 2 digits.
uploaded lastest backtrace. gdb_250510.txt

(gdb) frame 1
#1  0x080dcffb in ast_dsp_process (chan=0xb9636f8, dsp=0xb967718, af=0xb302d4c8) at dsp.c:1416
1416                                    memmove(&dsp->digit_state.digits[0], &dsp->digit_state.digits[1], dsp->digit_state.current_digits);
(gdb) p  dsp->digit_state.current_digits
$1 = 16777215
(gdb) p dsp->digit_state.digits[0]
$2 = 0 '\0'
(gdb) p dsp->digit_state.digits[1]
$3 = 0 '\0'
(gdb)



By: Digium Subversion (svnbot) 2010-06-05 12:55:28

Repository: asterisk
Revision: 268456

U   trunk/main/dsp.c

------------------------------------------------------------------------
r268456 | tilghman | 2010-06-05 12:55:27 -0500 (Sat, 05 Jun 2010) | 14 lines

Fix crash in DTMF detection.

What I did not originally see in my previous commit was that even though the
next digit could be detected before the previous was considered ended, the
detection of the next digit effectively ends the detection of the previous.
Therefore, the length moves in lockstep with the digit, and no separate counter
is needed for the length alone.

(closes issue ASTERISK-16125)
Reported by: alecdavis

(closes issue ASTERISK-16215)
Reported by: kenner

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

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

By: Digium Subversion (svnbot) 2010-06-05 12:56:55

Repository: asterisk
Revision: 268457

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

------------------------------------------------------------------------
r268457 | tilghman | 2010-06-05 12:56:54 -0500 (Sat, 05 Jun 2010) | 21 lines

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

........
 r268456 | tilghman | 2010-06-05 12:55:28 -0500 (Sat, 05 Jun 2010) | 14 lines
 
 Fix crash in DTMF detection.
 
 What I did not originally see in my previous commit was that even though the
 next digit could be detected before the previous was considered ended, the
 detection of the next digit effectively ends the detection of the previous.
 Therefore, the length moves in lockstep with the digit, and no separate counter
 is needed for the length alone.
 
 (closes issue ASTERISK-16125)
  Reported by: alecdavis
 
 (closes issue ASTERISK-16215)
  Reported by: kenner
........

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

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