[Home]

Summary:ASTERISK-08914: Call parking causes crash/deadlock
Reporter:Phoebe Anderson (phoebe)Labels:
Date Opened:2007-03-01 09:22:33.000-0600Date Closed:2007-03-02 11:23:44.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:1) SIP/A calls SIP/B
2) SIP/B does a feature park
3a) SIP/B retrieves call: Asterisk deadlocks
3b) Call remains parked: Asterisk crashes occasionally

3a) -- Executing Dial("SIP/227-081ea9c0", "SIP/221||tT") in new stack
   -- Called 221
   -- SIP/221-081ed5e0 is ringing
   -- SIP/221-081ed5e0 answered SIP/227-081ea9c0
   -- Started music on hold, class 'default', on SIP/227-081ea9c0
   -- Playing 'pbx-transfer' (language 'en')
   -- Stopped music on hold on SIP/227-081ea9c0
   -- Started music on hold, class 'default', on SIP/227-081ea9c0
 == Parked SIP/227-081ea9c0 on 91. Will timeout back to extension [outgoing] 221, 1 in 120 seconds
   -- Added extension '91' priority 1 to parkedcalls
   -- Playing 'digits/9' (language 'en')
   -- Playing 'digits/1' (language 'en')
Mar  1 09:58:40 WARNING[7744]: channel.c:2268 ast_write: Thread 98310 Blocking 'SIP/227-081ea9c0', already blocked by thread 98310 in procedure ast_waitfor_nandfds
   -- Executing ParkedCall("SIP/221-081ed5e0", "91") in new stack
   -- Playing 'beep' (language 'en')
   -- Stopped music on hold on SIP/227-081ea9c0
   -- Channel SIP/221-081ed5e0 connected to parked call 91
Mar  1 09:58:42 WARNING[8044]: channel.c:1604 ast_waitfor_nandfds: Thread 360464 Blocking 'SIP/227-081ea9c0', already blocked by thread 245774 in procedure ast_waitfor_nandfds
Mar  1 09:58:43 WARNING[8044]: channel.c:929 ast_channel_free: PBX may not have been terminated properly on 'SIP/227-081ea9c0'
 == Spawn extension (outgoing, 91, 1) exited non-zero on 'SIP/221-081ed5e0'
Mar  1 09:58:43 WARNING[7991]: channel.c:897 ast_channel_free: Unable to find channel in list

3b) -- Executing Dial("SIP/227-08185540", "SIP/221||tT") in new stack
   -- Called 221
   -- SIP/221-081af8e8 is ringing
   -- SIP/221-081af8e8 answered SIP/227-08185540
   -- Started music on hold, class 'default', on SIP/227-08185540
   -- Playing 'pbx-transfer' (language 'en')
   -- Stopped music on hold on SIP/227-08185540
   -- Started music on hold, class 'default', on SIP/227-08185540
 == Parked SIP/227-08185540 on 91. Will timeout back to extension [outgoing] 221, 1 in 120 seconds
   -- Added extension '91' priority 1 to parkedcalls
   -- Playing 'digits/9' (language 'en')
   -- Playing 'digits/1' (language 'en')
Mar  1 10:01:46 WARNING[8127]: channel.c:2268 ast_write: Thread 98310 Blocking 'SIP/227-08185540', already blocked by thread 98310 in procedure ast_waitfor_nandfds
   -- Stopped music on hold on SIP/227-08185540
 == t?"@t?"@08185540 got tired of being parked
Mar  1 10:01:55 WARNING[8127]: channel.c:897 ast_channel_free: Unable to find channel in list
test6*CLI>
Disconnected from Asterisk server
Executing last minute cleanups

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

features.conf

[general]
parkext => 7                  
parkpos => 91-99              
context => parkedcalls
parkingtime => 120
transferdigittimeout => 2
courtesytone = beep
xfersound = beep
xferfailsound = beeperr
featuredigittimeout = 1500

[featuremap]
blindxfer => *7
atxfer => *6
Comments:By: Phoebe Anderson (phoebe) 2007-03-01 09:38:38.000-0600

This seems to be related to the modifications in 1.2 as of revision 51145 from issue 8804.
By: Serge Vecher (serge-v) 2007-03-01 09:56:59.000-0600

what happens if you check 1.2 out from svn; if still a problem, let's see a backtrace ... http://www.voip-info.org/tiki-index.php?page=Asterisk%20debugging.
By: Tilghman Lesher (tilghman) 2007-03-01 10:45:57.000-0600

We're also seeing this problem when someone does a blind transfer (incorrectly) to Call Park, instead of doing an assisted transfer (correctly) to Call Park.
By: Phoebe Anderson (phoebe) 2007-03-01 12:08:44.000-0600

The issue is not reproduceable under SVN-branch-1.2-r57118M.  SVN code appears to be working properly.
By: Joshua C. Colp (jcolp) 2007-03-02 11:23:43.000-0600

Okay, confirmed this has been fixed in latest SVN.

For Corydon: Per our discussion yesterday the code flow for this versus a SIP based transfer is quite different so if you can get some logs and info for your issue let's open a new bug for that.