[Home]

Summary:ASTERISK-19184: Crash at attempt to attended transfer a call
Reporter:Aleksandr Gordeev (axonaro)Labels:
Date Opened:2012-01-11 06:44:59.000-0600Date Closed:2012-02-03 10:32:01.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Resources/res_fax_spandsp
Versions:10.0.0 10.1.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) 19184_simple_patch.diff
( 1) backtrace_10.1.0.txt
( 2) backtrace_rc.txt
( 3) backtrace_rc2.txt
( 4) backtrace.txt
( 5) verbose_debug_log.txt
Description:At attempt to attended transfer a call, there is a crash of asterisk.

In sip.conf

[asterisk10]
context=from-office
setvar=FAXOPT(gateway)=yes

[spa3102_line1]
context=from-gordeev

In extensions.conf

[from-office]
exten => 123456,1,Dial(SIP/spa3102_line1,,Tt)
exten => 123456,n,Hangup

[from-gordeev]
exten => _X.,1,Dial(SIP/asterisk10/${EXTEN})
exten => _X.,n,Hangup


Actions for reproduce :
1) Make incoming call from office over asterisk10 to 123456
2) Make attended transfer to office phone (765432) over asterisk10
3) Hangup on spa3102_line1

My schema :
ZoIPer -> asterisk 1.4.35 -> asterisk 10 -> Linksys

Without "FAXOPT(gateway)=yes" is done.
Comments:By: Matt Jordan (mjordan) 2012-01-11 08:18:20.262-0600

Thank you for your bug report. In order to move your issue forward, we require a backtrace[1] from the core file produced after the crash. Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then:

make install

After enabling, reproduce the crash, and then execute the backtrace[1] instructions. When complete, attach that file to this issue report.

[1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace

Just to clarify - does the crash occur when you set "FAXOPT(gateway)=yes", or when you do not have it set?
By: Aleksandr Gordeev (axonaro) 2012-01-11 23:29:07.131-0600

>Just to clarify - does the crash occur when you
>set"FAXOPT(gateway)=yes", or when you do not have it set?
Crash occur Only with set"FAXOPT(gateway)=yes", without all the work
By: Aleksandr Gordeev (axonaro) 2012-01-12 00:40:43.353-0600

new backtrace
By: Matt Jordan (mjordan) 2012-01-12 09:13:01.179-0600

Alexandr - a few questions.

1) The backtrace you've attached doesn't look like it came from an instance of Asterisk that was compiled with DONT_OPTIMIZE.  Can you confirm that you used the menuselect tool to enable DONT_OPTIMIZE, and reproduce the crash using that compiled version of Asterisk?
2) I'm unable to reproduce this in 10.1.  When doing the attended transfer, are you using the attended transfer feature set up through features.conf, or is it a SIP attended transfer?
3) Can you attach a DEBUG Asterisk log showing the steps you're taking when the crash occurs?

Thanks!
By: Aleksandr Gordeev (axonaro) 2012-01-13 00:22:17.632-0600

1) Sorry, I did a package for Debian is, it seems somewhere there was an error.
2) I am using the attended transfer feature set up through features.conf (attended transfer is set to #2).
3) I made a new backtrace and logs.
By: Aleksandr Gordeev (axonaro) 2012-01-13 00:23:32.188-0600

backtrace and logs
By: Aleksandr Gordeev (axonaro) 2012-01-18 00:12:27.635-0600

With asterisk-10.1.0-rc1 problem is present.
By: Aleksandr Gordeev (axonaro) 2012-01-18 01:09:01.737-0600

backtrace for asterisk-10.1.0-rc1
By: Aleksandr Gordeev (axonaro) 2012-01-25 04:22:13.227-0600

backtrace for asterisk-10.1.0-rc2
By: Aleksandr Gordeev (axonaro) 2012-01-30 04:28:18.638-0600

backtrace for asterisk-10.1.0
By: Jonathan Rose (jrose) 2012-01-30 15:32:40.566-0600

Alright, the cause is pretty obvious going by the backtrace.
if (!(details = find_details(chan))) {
only executes the nested lines if it sets details to null, and the action it performs here in response to that:
details->gateway_id = -1;

is guaranteed to segfault because it is trying to set a value on a null struct... which is bad.  I can't imagine Matt would have overlooked something like that if he was deliberately doing this when the details couldn't be found and the condition might be the typo, but kpfleming thinks the condition looks correct and the actual setting of details->gateway_id was the mistake.  It's hard to say for sure now that Matt is gone.

Workaround at this second would be to just blank out that line (setting details->gateway_id = -1) since it is unconditionally useless as long as details is null.  That should stop the segfault. Someone still needs to look at this to figure out what the intent of this code was.
By: Jonathan Rose (jrose) 2012-02-02 11:25:04.677-0600

Please test this patch:
19184_simple_patch.diff
By: Aleksandr Gordeev (axonaro) 2012-02-03 04:27:58.760-0600

Thank you.
With this patch all working, but showing this "[2012-02-03 13:25:17] ERROR[27845]: res_fax.c:2892 fax_gateway_framehook: no FAX session details found on chan Transfered/SIP/asterisk10-00000003<ZOMBIE> for T.38 gateway session, odd"
By: Jonathan Rose (jrose) 2012-02-03 10:11:47.102-0600

Well, that error was still expected since all we did was keep it from segfaulting.  This isn't actually a fax call is it?  I was under the impression that you just set fax gateway mode to on for a regular call that you were performing an attended transfer on.  

I'm not very familiar with fax gateway stuff, so I don't know whether or not that error means anything in relation to normal calls.  You might only want to enable gateway mode on channels that are only expecting fax.  In any event, I'll go ahead and commit this since it fixes the crash.  Open a new issue if that error is actually causing any problems.
By: Aleksandr Gordeev (axonaro) 2012-02-05 22:45:45.999-0600

I can not foresee the type of call, may be a fax, maybe not.