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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13681 
====================================================================== 
Reported By:                fhackenberger
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13681
Category:                   Core/Channels
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
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:              
====================================================================== 
Date Submitted:             2008-10-13 11:27 CDT
Last Modified:              2009-02-10 13:55 CST
====================================================================== 
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().
====================================================================== 

---------------------------------------------------------------------- 
 (0099835) file (administrator) - 2009-02-10 13:55
 http://bugs.digium.com/view.php?id=13681#c99835 
---------------------------------------------------------------------- 
I don't believe this is actually the solution to the problem here. We need
to figure out why either chan_sip did not queue a hangup frame and write to
the alert pipe or why that was not acted upon properly in the bridging
core. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-10 13:55 file           Note Added: 0099835                          
======================================================================