[asterisk-bugs] [Asterisk 0013681]: [patch] Asterisk sleeps forever in poll() when terminating both SIP endpoints of a bridged channel

[Asterisk Bug Tracker]

The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=13681 
====================================================================== 
Reported By:                fhackenberger
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   13681
Category:                   Core/Channels
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     resolved
Asterisk Version:           1.4.17 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 141156 
Request Review:              
Resolution:                 no change required
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-10-13 11:27 CDT
Last Modified:              2009-03-12 12:28 CDT
====================================================================== 
Summary:                    [patch] Asterisk sleeps forever in poll() when
terminating both SIP endpoints of a bridged channel
Description: 
As you can see from the following backtrace, the thread bridging the two
SIP channels is within poll(), which is called with -1 for the timeout
parameter. The file descriptors it watches are the associated UDP sockets
(which never get any IO again, because the endpoints are terminated), as
well as the alert and timing pipe. On my system this poll never returns
(waited more than 30 minutes).

Thread 3 (Thread 0xb547bb90 (LWP 10734)):
http://bugs.digium.com/view.php?id=0  0xb7ef3410 in __kernel_vsyscall ()
http://bugs.digium.com/view.php?id=1  0xb7dc7c07 in poll () from
/lib/tls/i686/cmov/libc.so.6
http://bugs.digium.com/view.php?id=2  0x08086f48 in ast_waitfor_nandfds
(c=0xb54743f0, n=2, fds=0x0, nfds=0,
exception=0x0, outfd=0x0, ms=0xb5474404) at channel.c:2026
http://bugs.digium.com/view.php?id=3  0x0808a6bd in ast_channel_bridge
(c0=0xb5327e48, c1=0xb58a4be0,
config=0xb5474c08, fo=0xb54744cc, rc=0xb54744c8) at channel.c:2088
http://bugs.digium.com/view.php?id=4  0xb73428cd in ast_bridge_call
(chan=0xb5327e48, peer=0xb58a4be0,
config=0xb5474c08) at res_features.c:1483
http://bugs.digium.com/view.php?id=5  0xb6cf9410 in try_calling (qe=0xb5476888,
options=<value optimized
out>, announceoverride=0xb54767f8 "", url=0xb54767f7 "", tries=0xb5476880,
    noption=0xb547687c, agi=0x0) at app_queue.c:3077
http://bugs.digium.com/view.php?id=6  0xb6cfd41f in queue_exec (chan=0xb5327e48,
data=0xb5476b08) at
app_queue.c:3940
http://bugs.digium.com/view.php?id=7  0x080c376e in pbx_exec (c=0xb5327e48,
app=0x833d6e0, data=0xb5476b08)
at pbx.c:532
http://bugs.digium.com/view.php?id=8  0xb6d82741 in realtime_exec
(chan=0xb5327e48, context=0x835ee13
"queues", exten=0xb5328018 "9001", priority=5, callerid=0xb53bc5f0 "sipp",
    data=0x83640c1 "@") at pbx_realtime.c:216
http://bugs.digium.com/view.php?id=9  0x080cb897 in pbx_extension_helper
(c=0xb5327e48, con=0x0,
context=0x835ee13 "queues", exten=0xb5328018 "9001", priority=5,
label=0x0,
    callerid=0xb53bc5f0 "sipp", action=E_SPAWN) at pbx.c:1862
http://bugs.digium.com/view.php?id=10 0x080cd5a9 in __ast_pbx_run (c=0xb5327e48)
at pbx.c:2306
http://bugs.digium.com/view.php?id=11 0x080ce46e in pbx_thread (data=0xb5327e48)
at pbx.c:2623
http://bugs.digium.com/view.php?id=12 0x080fe4bb in dummy_start
(data=0xb5304090) at utils.c:852
http://bugs.digium.com/view.php?id=13 0xb7eb74fb in start_thread () from
/lib/tls/i686/cmov/libpthread.so.0
http://bugs.digium.com/view.php?id=14 0xb7dd1e5e in clone () from
/lib/tls/i686/cmov/libc.so.6

Here is the full backtrace of all threads:
http://pastebin.com/fa7d0582

The attached workaround patch fixes this problem. It makes sure that the
parameter bridge_end.tv_sec passed to ast_generic_bridge is always set to
!=0. If that is not the case, ast_generic_bridge passes -1 to poll().
====================================================================== 

---------------------------------------------------------------------- 
 (0101669) file (administrator) - 2009-03-12 12:28
 http://bugs.digium.com/view.php?id=13681#c101669 
---------------------------------------------------------------------- 
After looking at this issue closer and examining things I've come to the
conclusion that this was an issue with handling of the SIP message causing
the channel to never get hung up, thus causing this issue. I've looked
through the commits and found numerous ones that fix this issue. I'm
closing this out because I strongly feel that these resolved the issue some
time ago. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-12 12:28 file           Note Added: 0101669                          
2009-03-12 12:28 file           Status                   acknowledged =>
resolved
2009-03-12 12:28 file           Resolution               open => no change
required
2009-03-12 12:28 file           Assigned To               => file            
======================================================================