[Home]

Summary:ASTERISK-11978: crash on call transfer
Reporter:vi (vi)Labels:
Date Opened:2008-05-06 09:04:31Date Closed:2011-06-07 14:00:43
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) output.txt
Description:asterisk 1.4.19.1 crashes when I try to transfer a call from one SIP phone to another.

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

(gdb) bt full
#0  0xb7fa5e2a in pthread_kill () from /lib/tls/libpthread.so.0
No symbol table info available.
#1  0xb7d04c1d in park_call_full (chan=0x82a3980, peer=0x82a4228, timeout=0, extout=0xb6bf981c, orig_chan_name=0x0) at res_features.c:396
       pu = (struct parkeduser *) 0x8237148
       cur = (struct parkeduser *) 0x0
       i = 0
       x = 701
       parking_range = 50
       con = (struct ast_context *) 0xb6bf97d8
       parkingexten = 0x0
#2  0xb7d051ab in ast_park_call (chan=0x82a3980, peer=0x82a4228, timeout=0, extout=0xb6bf981c) at res_features.c:452
No locals.
#3  0xb7b86ae3 in sip_park_thread (stuff=0x82a9850) at chan_sip.c:13079
       transferee = (struct ast_channel *) 0x82a3980
       transferer = (struct ast_channel *) 0x82a4228
       d = (struct sip_dual *) 0x82a9850
       req = {rlPart1 = 0xb6bf9a3c "REFER", rlPart2 = 0xb6bf9a42 "sip:9629926520@81.88.208.137", len = 647, headers = 14, method = 9, lines = 0, flags = 0, header = {0xb6bf9a3c "REFER",
   0xb6bf9a68 "Via: SIP/2.0/UDP 10.199.199.156:5060;branch=z9hG4bKde0d0a32c8f738e7", 0xb6bf9aad "From: <sip:701@10.199.199.156:5060;transport=udp>;tag=3bf9502a511de432",
   0xb6bf9af5 "To: \"9629926520\" <sip:9629926520@81.88.208.137>;tag=as05062d81", 0xb6bf9b35 "Contact: <sip:701@10.199.199.156:5060;transport=udp>", 0xb6bf9b6b "Supported: replaces, path",
   0xb6bf9b86 "Refer-To: <sip:700@81.88.208.137>", 0xb6bf9ba9 "Referred-By: <sip:701@81.88.208.137>", 0xb6bf9bcf "Call-ID: 65ec12153ebd97765486ac376573554a@81.88.208.137", 0xb6bf9c08 "CSeq: 42726 REFER",
   0xb6bf9c1b "User-Agent: Grandstream GXP2020 1.1.6.16", 0xb6bf9c45 "Max-Forwards: 70", 0xb6bf9c57 "Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE",
   0xb6bf9cae "Content-Length: 0", 0xb7b3bc11 "", 0x0 <repeats 49 times>}, line = {0xb7b3bc13 "", 0x0 <repeats 63 times>},
 data = "REFER\000sip:9629926520@81.88.208.137\000SIP/2.0\000\000Via: SIP/2.0/UDP 10.199.199.156:5060;branch=z9hG4bKde0d0a32c8f738e7\000\000From: <sip:701@10.199.199.156:5060;transport=udp>;tag=3bf9502a511de432\000\000To: \"9629926520"..., sdp_start = 0, sdp_end = 0}
       ext = 701
       res = 136602208
#4  0x08112453 in dummy_start (data=0x8242e78) at utils.c:865
       _buffer = {__routine = 0x8069bb2 <ast_unregister_thread>, __arg = 0xb6bfabb0, __canceltype = -1208841984, __prev = 0x0}
       ret = (void *) 0xb7f03ae2
       a = {start_routine = 0xb7b86868 <sip_park_thread>, data = 0x82a9850, name = 0x82a4f38 "sip_park_thread      started at [13204] chan_sip.c sip_park()"}
       lock_info = (struct thr_lock_info *) 0x823a7f0
       mutex_attr = {__mutexkind = 1}
ASTERISK-1  0xb7fa2b63 in start_thread () from /lib/tls/libpthread.so.0
No symbol table info available.
ASTERISK-2  0xb7ece18a in clone () from /lib/tls/libc.so.6
No symbol table info available.



(gdb) up
#1  0xb7d04c1d in park_call_full (chan=0x82a3980, peer=0x82a4228, timeout=0, extout=0xb6bf981c, orig_chan_name=0x0) at res_features.c:396
396             pthread_kill(parking_thread, SIGURG);
Comments:By: David Woolley (davidw) 2008-05-06 12:52:00

This looks like a res_features issue, not a core one, and the call transfer is not to an ordinary extension, it is a SIP (blind?) transfer to the park a call extension, which is treated as a special case by the SIP channel.

Could you confirm that you are not overloading extensions 7xx, as there is also the use of 701 (retrieve first parked call) in what, seems to me, to be the extension number of the the transferror.

If this is not a conflict for the 7xx range, a full history of the call would be useful.  I suspect it would also be useful to have the exception that caused the crash and the value of parking_thread, and if it is a pointer, of *parking_thread.
By: David Woolley (davidw) 2008-05-06 16:45:42

On a quick look of the code, it looks like the parking thread isn't started if there is no features.conf, but the parking extension is still initialised to the default of "700", and ast_parking_ext returns it without checking whether parking is properly initialised.

The magic handling of transfers to the parking extension in the SIP channel doesn't check the result of ast_parking_ext before comparing it (which would make setting it to NULL unsafe).  Incidentally it also ignores the context in doing the check.

As a result, attempting a SIP transfer to 700 causes an attempt to send a signal to a thread whose thread descriptor hasn't been initialised.

If you are using 700 and 701 as real extensions, and don't have a features.conf, a workaround would be to add a features.conf and set the parking extension to something safe, maybe alphabetic.  I'm not sure if a proper fix can just get away with setting the value to an empty string, or whether that can be a legitimate target of a SIP transfer.

Please confirm that you don't have features.conf and that 700 and 701 are "real" extensions.
By: Michiel van Baak (mvanbaak) 2008-05-27 11:51:14

vi: can you please reply to davidw's comment ?
By: Antonio Gallo (agx) 2008-05-29 10:00:49

If you can look at ASTERISK-10623 also (its still an issue but i resolved removing parking functions from the PBX) its related.

I can confirm whats davidw is saying.
By: David Brillert (aragon) 2008-05-29 13:34:25

This looks like the same problem as http://bugs.digium.com/view.php?id=11979

Currently in feedback status also.
file is looking for backtrace
I have the same problem but also use the workaround jvandal used in bug report 11979 to remove segfault.
It would be great if someone could provide full bt to file so this problem can be properly fixed.

(0087452)
file - administrator
05-28-08 12:08

Since Junky hasn't looked at this I'll take a gander but I would like a new complete backtrace as an attachment and exact callflow to reproduce this.

I'll put a note on bug ID 11979 to reference your backtrace and ticket number
By: David Woolley (davidw) 2008-05-29 15:14:50

I don't believe this is the same as ASTERISK-11424.  That one is crashing in the parking thread, this one seems to have a problem with the existence of the parking thread.
By: Tilghman Lesher (tilghman) 2008-07-25 17:13:10

No response from the reporter in over a month.