[Home]

Summary:ASTERISK-16032: [patch] Crash when using Background() in Macro called by M() option to Dial()
Reporter:Private Name (falves11)Labels:
Date Opened:2010-04-29 17:27:12Date Closed:2010-05-28 12:57:41
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk_dial_crash.txt
( 1) crash_1.txt
( 2) crash_162.txt
( 3) crash_dial_1.txt
( 4) crash_dial.txt
( 5) crash_internal_obj.txt
( 6) issue_17264_1.6.1_reviewboard_fix.diff
( 7) issue_17264_1.6.2_reviewboard_fix.diff
( 8) issue_17264_reviewboard_fix.diff
( 9) issue_17264.diff
(10) issue17264_162.diff
(11) udptl_fixed.diff
Description:This the section where it blows up.

exten =>_X.,n,Dial(${CUT(CARRIERLIST,-,${i})},${CUT(TO,-,${i})},M(get-callid^${PROMPT})L(10800000)) ;dial once

[macro-get-callid]
exten => s,1,Verbose(2,Playing ${ARG1})
exten => s,n,GotoIf($["${ARG1}" = "0" ]?salida)
exten => s,n,Background(${ARG1})
exten => s,n(salida),MacroExit

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

I use only Sip2Sip.
Comments:By: Paul Belanger (pabelanger) 2010-04-29 17:46:16

falves11, you need to start providing more information on how to reproduce your issues.  At a minimum steps to reproduce and any necessary .configs or traces.

Just stating 'It crashes in...' does not help us triage the issue.

This has already been mentioned in another issue of yours.
By: David Woolley (davidw) 2010-04-29 17:49:22

No it doesn't crash in dial().  It looks like it crashes in background(), which is run on a macro, run from dial.

Incidentally, macros are deprecated in 1.6.1, so if the use of a macro is implicated (which it probably isn't), I'm not sure if it is supported.
By: Private Name (falves11) 2010-04-29 18:02:09

I use a macro to pay a file to the callee, before bridging the call. How do I replace this functionality in 1.6.X? It is an important functionality in many business scenarios. I use a macro because in some scenarios I don't play a file, but play date, etc.
By: David Woolley (davidw) 2010-04-29 18:30:55

I think I may have overstated the position on macros; I think I misinterpreted the scope of an AEL change.  There are alternatives to macros, but that is a support question.


In this case, even if the crash only happens under heavy load, you need to provide the dialplan.  It can be unreasonable to provide steps to reproduce for crashes, but it is not unreasonable to supply relevant configuration information.

If I were to debug it further, and, as it doesn't look relevant to our needs, I don't think I have that time, I might well need the values of various structures printing using gdb.
By: Private Name (falves11) 2010-04-29 18:33:36

My configuration and dialplan are available via email, as well as access to the boxes where these crashes occur.
By: Paul Belanger (pabelanger) 2010-04-29 18:53:56

You can upload the relevant sections of your dialplan and .configs to the issue tracker.  Be sure to XXX any sensitive information if it is an issue for you.
By: Private Name (falves11) 2010-04-29 21:03:31

This the section where it blows up.

exten =>_X.,n,Dial(${CUT(CARRIERLIST,-,${i})},${CUT(TO,-,${i})},M(get-callid^${PROMPT})L(10800000)) ;dial once

[macro-get-callid]
exten => s,1,Verbose(2,Playing ${ARG1})
exten => s,n,GotoIf($["${ARG1}" = "0" ]?salida)
exten => s,n,Background(${ARG1})
exten => s,n(salida),MacroExit


By: Leif Madsen (lmadsen) 2010-04-30 11:01:26

Modified the issue to be more descriptive of the problem. Thank you so much davidw for helping to triage this (and other) issue(s).
By: Private Name (falves11) 2010-05-11 18:28:06

I uploaded 3 additional traces, but kindly check the third one, for it may be a new issue. I just lack the criteria to tell.
By: Private Name (falves11) 2010-05-14 09:09:26

It crashes about 10 times per day. Please check the latest one.
By: Private Name (falves11) 2010-05-14 12:21:39

Please review this patch proposed and if you like it, I will upload as a file.
In all cores you can see a NULL deference from udptl. Watching caller
(interpret_t38_parameters) p is correct but p->udptl is NULL. Previous
member is zeroed but this indicate probably initialization to zero (not
used), all socket address structures are IPV4 so probably udptl was not
initialized. You could use a temporarily patch like this

<inline patch removed by lmadsen>


By: Leif Madsen (lmadsen) 2010-05-17 11:32:12

All patches must be uploaded as a file attachment and not inline.

But of course you already knew this.
By: Private Name (falves11) 2010-05-17 13:54:32

Kindly delete the patch file udptl.diff. It had an error and I uploaded the replacement, updtl_fixed.diff.
By: David Vossel (dvossel) 2010-05-19 14:39:41

#0  0x000000000051786c in ast_udptl_set_local_max_ifp (udptl=0x0, max_ifp=30) at udptl.c:869
869                     udptl->local_max_ifp = max_ifp;
(gdb) bt
#0  0x000000000051786c in ast_udptl_set_local_max_ifp (udptl=0x0, max_ifp=30) at udptl.c:869
#1  0x00002aaab0e45b56 in interpret_t38_parameters (p=0x2aaad9d0bd78, parameters=0x9fced60) at chan_sip.c:6054


If Asterisk is crashing in ast_udptl_set_local_max_ifp because the udptl struct is NULL, then the solution here should be to figure out why chan_sip is trying to set a udptl struct that hasn't been allocated yet.
By: David Vossel (dvossel) 2010-05-20 15:23:46

I uploaded a patch and started a discussion on reviewboard about it.

https://reviewboard.asterisk.org/r/671/
By: Private Name (falves11) 2010-05-25 08:02:03

I just uploaded the patch for version 1.6.2. It has been running for a couple of days without crashing.
By: David Vossel (dvossel) 2010-05-25 12:36:05

Please test one of the new patches I just uploaded as a conclusion of the Reviewboard discussion.  I made one for 1.6.1 as well even though it won't be committed.

*edit* The patch you are currently testing fixes the symptom, but these patches are attempting to eliminate the cause.  We should never get to the point were we are trying to set a value on a NULL udptl structure.


By: Private Name (falves11) 2010-05-28 11:50:51

I just uploaded a new 1.6.2 crash, it seems related, but I am unsure. Please advice if I need to open a separate bug report.
By: David Vossel (dvossel) 2010-05-28 12:05:48

Did you test my UDPTL patch yet?  I need to know if that resolves the UDPTL crash for you.  I know your patch will but I don't think that is the correct fix for in this instance.

No, that new back trace is not related to the UDPTL fix.  You have several back traces uploaded that are separate crashes.  I thought the one this issue was set out to resolve was the UDPTL one because that is the one you uploaded a patch for.  The new one you uploaded seems to be related to maybe the crash_1.txt which appears to me to be a completely separate issue from the UDPTL one that is reported in most of the others.
By: Private Name (falves11) 2010-05-28 12:10:40

I have been running with your patch since when you posted it, and this is the first crash I get. So it must work.
By: David Vossel (dvossel) 2010-05-28 12:39:08

Awesome, thanks for the feedback.  Since this issue appeared devoted to solving the UDPTL crash, please make a new issue for the most recent back trace you reported.  This issue will be closed shortly.
By: Private Name (falves11) 2010-05-28 12:43:02

I opened a new issue
https://issues.asterisk.org/view.php?id=17418

Kindly help me with this new issue. It seems that my bugs are always rejected without even looking at the traces. I cannot supply any additional debug or valgrind information, for my particular high volume application.
By: Digium Subversion (svnbot) 2010-05-28 12:55:38

Repository: asterisk
Revision: 266292

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r266292 | dvossel | 2010-05-28 12:55:38 -0500 (Fri, 28 May 2010) | 9 lines

fixes crash when creation of UDPTL fails

(closes issue ASTERISK-16032)
Reported by: falves11
Patches:
     issue_17264_reviewboard_fix.diff uploaded by dvossel (license 671)
     issue_17264_1.6.2_reviewboard_fix.diff uploaded by dvossel (license 671)
Tested by: falves11

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

http://svn.digium.com/view/asterisk?view=rev&revision=266292
By: Digium Subversion (svnbot) 2010-05-28 12:57:40

Repository: asterisk
Revision: 266293

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r266293 | dvossel | 2010-05-28 12:57:39 -0500 (Fri, 28 May 2010) | 16 lines

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

........
 r266292 | dvossel | 2010-05-28 12:55:38 -0500 (Fri, 28 May 2010) | 9 lines
 
 fixes crash when creation of UDPTL fails
 
 (closes issue ASTERISK-16032)
 Reported by: falves11
 Patches:
       issue_17264_reviewboard_fix.diff uploaded by dvossel (license 671)
       issue_17264_1.6.2_reviewboard_fix.diff uploaded by dvossel (license 671)
 Tested by: falves11
........

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

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