[Home]

Summary:ASTERISK-14074: Crash on attended transfer
Reporter:Massimo Nuvoli (maxnuv)Labels:
Date Opened:2009-05-06 04:47:51Date Closed:2009-09-01 15:45:45
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Addons/format_mp3
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bt1.txt
( 1) bt2.txt
( 2) log.txt
Description:Call incoming, first transfer (all ok), second transfer: call, the called respond, the trasferer hangup, SEGFAULT (before playng beep).

Two backtrace available, one old and one new.
Comments:By: Leif Madsen (lmadsen) 2009-05-07 12:19:17

Is this a SIP transfer, or built-in transfer?
By: Leif Madsen (lmadsen) 2009-05-07 12:19:41

Also can you provide the relative parts of the dialplan in order to reproduce this issue? Thanks!
By: Massimo Nuvoli (maxnuv) 2009-05-07 23:37:30

IMPORTANT:

This is the timeline of this call :-) :

SIP/223 called my phone number
SIP/223 transferred the call at SIP/210
SIP/210 transferred back the call at SIP/223

First, the "caller" was me :-) so i hear on the phone and see on the console wath appens at the segfault.

The call was incoming on line and was answered from a SIP phone with a queue, and transferred to a sip phone.

The call progress (number was 0121somethingnumber:

[from-telecom]

exten => (number),1,Noop(Numero ${EXTEN} entrata)
exten => (number),n,Set(CDR(accountcode)=entrata-gidi)
exten => (number),n,Set(CDR(userfield)=number)
exten => (number),n,Goto(e-standard|1

exten => e-standard,1,Noop(entrata standard)
exten => e-standard,n,Ringing()
exten => e-standard,n,Wait(3)
exten => e-standard,n,Queue(entrata|rtw)

so queue entrata is (queue.conf)

[entrata]
wrapuptime=1
retry = 5
strategy = ringall
member => SIP/211
member => SIP/218
member => SIP/210
member => SIP/217

So 210 answered.

210 pressed # (so this is why "maybe" this is attended transfer from the asterisk side, not the SIP PHONE feature i think).
dialed 223, the SIP 223 answered, a little talk with 210, when 210 hangup here the segfault, so you see the call between SIP 223 and SIP 210....

the extension on from-sip-u

[from-sip-u]
include=>from-sip-base
include=>from-sip-u-base

[from-sip-u-base]

... snip ...

exten => _2XX,1,Noop(Interno ${EXTEN})
exten => _2XX,n,Set(__CHIAMANTE=${CALLERID(num)})
exten => _2XX,n,Set(CDR(accountcode)=da ${CHIAMANTE})
exten => _2XX,n,Set(__INTERNO=${EXTEN})
exten => _2XX,n,Set(CDR(userfield)=${INTERNO})
exten => _2XX,n,Dial(SIP/${EXTEN}||rtTw)
exten => _2XX,n,Goto(interno-${DIALSTATUS}|1) ; Jump based on status (NOANSWER,BUSY,CHANUNAVAIL,CONGESTION,ANSWER)

if you think it is necessary i can put here all the extensions.conf.


By: Massimo Nuvoli (maxnuv) 2009-05-08 00:02:27

I found interesting this: in a normal call without segfault after the last line of the log:

[May  6 11:21:31] VERBOSE[13766] logger.c:     -- SIP/223-082968b0 answered Local/223@from-sip-u-d29f,2
[May  6 11:21:31] VERBOSE[13766] logger.c:   == Spawn extension (from-sip-u, 223, 6) exited non-zero on 'Local/223@from-sip-u-d29f,2'

continue with something like this (this is a SIMULATION of the log all things are wrong, date numbers channels etc. etc.).

The segfault seems to be HERE

[May  7 16:35:35] VERBOSE[19244] logger.c:     -- Stopped music on hold on WOOMERA/g3/6

Here the channel does the fixup (link the external line with the leg of the call 223)

[May  7 16:35:35] VERBOSE[19244] logger.c:     -- <SIP/223@from-sip-u-d29f,2> Playing 'beep' (language 'it')
[May  7 16:35:36] VERBOSE[19244] logger.c:   == Spawn extension (from-sip-u, chiama, 2) exited non-zero on 'SIP/210-b62384e8'

So i think the segfault can be on:

The moh

then

The fixup (and here the problem may be not asterisk but the channel)


By: Massimo Nuvoli (maxnuv) 2009-05-08 00:10:44

I checked the co line was called with:

exten => chiama,n,Dial(${GLT}||TW)

where GLT was WOOMERA/g2/(myphonenumber)
By: Leif Madsen (lmadsen) 2009-05-11 09:40:59

Please provide a backtrace with DONT_OPTIMIZE enabled in menuselect. See doc/backtrace.txt in your Asterisk source. Attach as a file to this issue when you have that. Thanks!
By: Leif Madsen (lmadsen) 2009-05-11 09:54:47

Ooops... ignore what I just said. Must still be early here -- I didn't see the backtraces you've uploaded already.
By: Mark Michelson (mmichelson) 2009-05-11 10:00:55

There are two somewhat "odd" items in this scenario.

1) The use of the woomera channel type
2) The use of format_mp3 from asterisk-addons

I would recommend that tests be run first without 1), then without 2), and then without both. That way we might be able to tell more easily where the problem lies.

Keep in mind that if the problem is in chan_woomera, you will need to report the problem to the maintainer of that channel driver since it is not officially supported by the Asterisk project.
By: Massimo Nuvoli (maxnuv) 2009-05-12 02:38:10

As i found the use of the woomera channel i posted a bug also to the developer of the channel driver.

The customer is using SIP trunks and WOOMERA trunks so i try to investigate more; i remember in the past some segfault with woomera, in the bt always was present some reference to this channel.

And i opened this bug as i think the problem is not the channel, but something in asterisk.

To avoid use of format_mp3 i converted the files from .mp3 to .wav.

Today no more segfaults, no changes in woomera -> maybe format_mp3?


By: Russell Bryant (russell) 2009-08-25 14:50:42

I have posted a patch on issue 15109 which should address this issue.  Please give it a try!

https://issues.asterisk.org/view.php?id=15109
By: Digium Subversion (svnbot) 2009-09-01 15:39:22

Repository: asterisk-addons
Revision: 1023

U   branches/1.4/formats/format_mp3.c

------------------------------------------------------------------------
r1023 | russell | 2009-09-01 15:38:54 -0500 (Tue, 01 Sep 2009) | 45 lines

Fix memory corruption caused by format_mp3.

format_mp3 claimed that it provided AST_FRIENDLY_OFFSET in frames returned by
read().  However, it lied.  This means that other parts of the code that
attempted to make use of the offset buffer would end up corrupting the fields
in the ast_filestream structure.  This resulted in quite a few crashes due to
unexpected values for fields in ast_filestream.

This patch closes out quite a few bugs.  However, some of these bugs have been
open for a while and have been an area where more than one bug has been
discussed.  So with that said, anyone that is following one of the issues
closed here, if you still have a problem, please open a new bug report for the
specific problem you are still having.  If you do, please ensure that the bug
report is based on the newest version of Asterisk, and that this patch is
applied if format_mp3 is in use.  Thanks!

(closes issue ASTERISK-14129)
Reported by: jvandal
Tested by: aragon, russell, zerohalo, marhbere, rgj

(closes issue ASTERISK-14007)
Reported by: aragon

(closes issue ASTERISK-14141)
Reported by: axisinternet

(closes issue ASTERISK-14074)
Reported by: maxnuv

(closes issue ASTERISK-14374)
Reported by: aragon

(closes issue ASTERISK-14203)
Reported by: amorsen
Tested by: amorsen

(closes issue ASTERISK-14718)
Reported by: jensvb

(closes issue ASTERISK-14673)
Reported by: thom4fun

(closes issue ASTERISK-14428)
Reported by: marhbere

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

http://svn.digium.com/view/asterisk-addons?view=rev&revision=1023
By: Digium Subversion (svnbot) 2009-09-01 15:40:31

Repository: asterisk-addons
Revision: 1024

U   branches/1.6.0/formats/format_mp3.c

------------------------------------------------------------------------
r1024 | russell | 2009-09-01 15:40:16 -0500 (Tue, 01 Sep 2009) | 45 lines

Fix memory corruption caused by format_mp3.

format_mp3 claimed that it provided AST_FRIENDLY_OFFSET in frames returned by
read().  However, it lied.  This means that other parts of the code that
attempted to make use of the offset buffer would end up corrupting the fields
in the ast_filestream structure.  This resulted in quite a few crashes due to
unexpected values for fields in ast_filestream.

This patch closes out quite a few bugs.  However, some of these bugs have been
open for a while and have been an area where more than one bug has been
discussed.  So with that said, anyone that is following one of the issues
closed here, if you still have a problem, please open a new bug report for the
specific problem you are still having.  If you do, please ensure that the bug
report is based on the newest version of Asterisk, and that this patch is
applied if format_mp3 is in use.  Thanks!

(closes issue ASTERISK-14129)
Reported by: jvandal
Tested by: aragon, russell, zerohalo, marhbere, rgj

(closes issue ASTERISK-14007)
Reported by: aragon

(closes issue ASTERISK-14141)
Reported by: axisinternet

(closes issue ASTERISK-14074)
Reported by: maxnuv

(closes issue ASTERISK-14374)
Reported by: aragon

(closes issue ASTERISK-14203)
Reported by: amorsen
Tested by: amorsen

(closes issue ASTERISK-14718)
Reported by: jensvb

(closes issue ASTERISK-14673)
Reported by: thom4fun

(closes issue ASTERISK-14428)
Reported by: marhbere

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

http://svn.digium.com/view/asterisk-addons?view=rev&revision=1024
By: Digium Subversion (svnbot) 2009-09-01 15:42:38

Repository: asterisk-addons
Revision: 1025

U   branches/1.6.1/formats/format_mp3.c

------------------------------------------------------------------------
r1025 | russell | 2009-09-01 15:42:24 -0500 (Tue, 01 Sep 2009) | 45 lines

Fix memory corruption caused by format_mp3.

format_mp3 claimed that it provided AST_FRIENDLY_OFFSET in frames returned by
read().  However, it lied.  This means that other parts of the code that
attempted to make use of the offset buffer would end up corrupting the fields
in the ast_filestream structure.  This resulted in quite a few crashes due to
unexpected values for fields in ast_filestream.

This patch closes out quite a few bugs.  However, some of these bugs have been
open for a while and have been an area where more than one bug has been
discussed.  So with that said, anyone that is following one of the issues
closed here, if you still have a problem, please open a new bug report for the
specific problem you are still having.  If you do, please ensure that the bug
report is based on the newest version of Asterisk, and that this patch is
applied if format_mp3 is in use.  Thanks!

(closes issue ASTERISK-14129)
Reported by: jvandal
Tested by: aragon, russell, zerohalo, marhbere, rgj

(closes issue ASTERISK-14007)
Reported by: aragon

(closes issue ASTERISK-14141)
Reported by: axisinternet

(closes issue ASTERISK-14074)
Reported by: maxnuv

(closes issue ASTERISK-14374)
Reported by: aragon

(closes issue ASTERISK-14203)
Reported by: amorsen
Tested by: amorsen

(closes issue ASTERISK-14718)
Reported by: jensvb

(closes issue ASTERISK-14673)
Reported by: thom4fun

(closes issue ASTERISK-14428)
Reported by: marhbere

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

http://svn.digium.com/view/asterisk-addons?view=rev&revision=1025
By: Digium Subversion (svnbot) 2009-09-01 15:43:28

Repository: asterisk-addons
Revision: 1026

U   branches/1.6.2/formats/format_mp3.c

------------------------------------------------------------------------
r1026 | russell | 2009-09-01 15:43:13 -0500 (Tue, 01 Sep 2009) | 45 lines

Fix memory corruption caused by format_mp3.

format_mp3 claimed that it provided AST_FRIENDLY_OFFSET in frames returned by
read().  However, it lied.  This means that other parts of the code that
attempted to make use of the offset buffer would end up corrupting the fields
in the ast_filestream structure.  This resulted in quite a few crashes due to
unexpected values for fields in ast_filestream.

This patch closes out quite a few bugs.  However, some of these bugs have been
open for a while and have been an area where more than one bug has been
discussed.  So with that said, anyone that is following one of the issues
closed here, if you still have a problem, please open a new bug report for the
specific problem you are still having.  If you do, please ensure that the bug
report is based on the newest version of Asterisk, and that this patch is
applied if format_mp3 is in use.  Thanks!

(closes issue ASTERISK-14129)
Reported by: jvandal
Tested by: aragon, russell, zerohalo, marhbere, rgj

(closes issue ASTERISK-14007)
Reported by: aragon

(closes issue ASTERISK-14141)
Reported by: axisinternet

(closes issue ASTERISK-14074)
Reported by: maxnuv

(closes issue ASTERISK-14374)
Reported by: aragon

(closes issue ASTERISK-14203)
Reported by: amorsen
Tested by: amorsen

(closes issue ASTERISK-14718)
Reported by: jensvb

(closes issue ASTERISK-14673)
Reported by: thom4fun

(closes issue ASTERISK-14428)
Reported by: marhbere

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

http://svn.digium.com/view/asterisk-addons?view=rev&revision=1026
By: Digium Subversion (svnbot) 2009-09-01 15:45:12

Repository: asterisk
Revision: 215212

U   trunk/addons/format_mp3.c

------------------------------------------------------------------------
r215212 | russell | 2009-09-01 15:44:57 -0500 (Tue, 01 Sep 2009) | 45 lines

Fix memory corruption caused by format_mp3.

format_mp3 claimed that it provided AST_FRIENDLY_OFFSET in frames returned by
read().  However, it lied.  This means that other parts of the code that
attempted to make use of the offset buffer would end up corrupting the fields
in the ast_filestream structure.  This resulted in quite a few crashes due to
unexpected values for fields in ast_filestream.

This patch closes out quite a few bugs.  However, some of these bugs have been
open for a while and have been an area where more than one bug has been
discussed.  So with that said, anyone that is following one of the issues
closed here, if you still have a problem, please open a new bug report for the
specific problem you are still having.  If you do, please ensure that the bug
report is based on the newest version of Asterisk, and that this patch is
applied if format_mp3 is in use.  Thanks!

(closes issue ASTERISK-14129)
Reported by: jvandal
Tested by: aragon, russell, zerohalo, marhbere, rgj

(closes issue ASTERISK-14007)
Reported by: aragon

(closes issue ASTERISK-14141)
Reported by: axisinternet

(closes issue ASTERISK-14074)
Reported by: maxnuv

(closes issue ASTERISK-14374)
Reported by: aragon

(closes issue ASTERISK-14203)
Reported by: amorsen
Tested by: amorsen

(closes issue ASTERISK-14718)
Reported by: jensvb

(closes issue ASTERISK-14673)
Reported by: thom4fun

(closes issue ASTERISK-14428)
Reported by: marhbere

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

http://svn.digium.com/view/asterisk?view=rev&revision=215212
By: Digium Subversion (svnbot) 2009-09-01 15:45:43

Repository: asterisk
Revision: 215213

_U  branches/1.6.2/

------------------------------------------------------------------------
r215213 | russell | 2009-09-01 15:45:26 -0500 (Tue, 01 Sep 2009) | 51 lines

Blocked revisions 215212 via svnmerge

........
 r215212 | russell | 2009-09-01 15:44:13 -0500 (Tue, 01 Sep 2009) | 45 lines
 
 Fix memory corruption caused by format_mp3.
 
 format_mp3 claimed that it provided AST_FRIENDLY_OFFSET in frames returned by
 read().  However, it lied.  This means that other parts of the code that
 attempted to make use of the offset buffer would end up corrupting the fields
 in the ast_filestream structure.  This resulted in quite a few crashes due to
 unexpected values for fields in ast_filestream.
 
 This patch closes out quite a few bugs.  However, some of these bugs have been
 open for a while and have been an area where more than one bug has been
 discussed.  So with that said, anyone that is following one of the issues
 closed here, if you still have a problem, please open a new bug report for the
 specific problem you are still having.  If you do, please ensure that the bug
 report is based on the newest version of Asterisk, and that this patch is
 applied if format_mp3 is in use.  Thanks!
 
 (closes issue ASTERISK-14129)
 Reported by: jvandal
 Tested by: aragon, russell, zerohalo, marhbere, rgj
 
 (closes issue ASTERISK-14007)
 Reported by: aragon
 
 (closes issue ASTERISK-14141)
 Reported by: axisinternet
 
 (closes issue ASTERISK-14074)
 Reported by: maxnuv
 
 (closes issue ASTERISK-14374)
 Reported by: aragon
 
 (closes issue ASTERISK-14203)
 Reported by: amorsen
 Tested by: amorsen
 
 (closes issue ASTERISK-14718)
 Reported by: jensvb
 
 (closes issue ASTERISK-14673)
 Reported by: thom4fun
 
 (closes issue ASTERISK-14428)
 Reported by: marhbere
........

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

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