[asterisk-bugs] [Asterisk 0016774]: 1.6.1.13 and 1.6.1.14 UDP ports not freed =>
Asterisk Bug Tracker
noreply at bugs.digium.com
Wed Feb 10 07:55:58 CST 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=16774
======================================================================
Reported By: kowalma
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 16774
Category: Core/RTP
Reproducibility: always
Severity: block
Priority: normal
Status: feedback
Target Version: Potential Blocker
Asterisk Version: 1.6.1.14
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2010-02-04 12:46 CST
Last Modified: 2010-02-10 07:55 CST
======================================================================
Summary: 1.6.1.13 and 1.6.1.14 UDP ports not freed =>
Description:
Since 1.6.1.13 looks there is problem with freeing UDP ports. 2-3 days ago
I upgraded one box from 1.6.0.5 and second from 1.6.1.1 to 1.6.1.13 and
every few thusants calls I'm running out of UDP ports.
mg0:~# rasterisk -x " sip show channels"
Peer User/ANR Call ID Format Hold
Last Message Expiry
192.168.9.2 mg0 28f9a3d00edd874 0x8 (alaw) No
Rx: ACK
192.168.9.2 mg0 77d13e113c8409e 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 7297a36515d38d1 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 07b22e6a461f5b3 0x8 (alaw) No
Rx: INVITE
192.168.9.2 mg0 3076b8603492c24 0x8 (alaw) No
Rx: ACK
192.168.9.2 mg0 30180433452ebf7 0x8 (alaw) No
Rx: INVITE
192.168.9.2 mg0 28c1ad56233d208 0x8 (alaw) No
Rx: INVITE
192.168.9.2 mg0 0182d70a3ec9d14 0x8 (alaw) No
Rx: INVITE
192.168.9.2 mg0 76a5f0c46328c99 0x8 (alaw) No
Rx: ACK
192.168.9.2 mg0 56be88b8268d261 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 626ef5624a83e0c 0x0 (nothing) No
Rx: ACK
192.168.9.2 mg0 1af2adc275f0b10 0x8 (alaw) No
Rx: ACK
192.168.9.2 mg0 645b2a390a66a11 0x0 (nothing) No
Rx: ACK
192.168.9.2 mg0 502a709e10ff8dc 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 58ab1eac5e50a92 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 6967aeee16f8e71 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 618b46651909df3 0x8 (alaw) No
Rx: INVITE
192.168.9.2 mg0 4ddae9dc5f91236 0x8 (alaw) No
Rx: INVITE
192.168.9.2 mg0 250e1d32111b2c5 0x0 (nothing) No
Rx: ACK
192.168.9.2 mg0 72cfef2c5fc67eb 0x8 (alaw) No
Rx: INVITE
192.168.9.2 mg0 6d70624c7eb9942 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 5e2c546e27a0af2 0x8 (alaw) No
Rx: INVITE
192.168.9.2 mg0 53fa535541908ce 0x8 (alaw) No
Rx: ACK
192.168.9.2 mg0 0f8cb2514fd7e4f 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 5cdeead033ebb17 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 4083b3aa6c3a4c5 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 4bd036370f2ac5d 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 50467ac42828e9d 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 17faaccd5554f00 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 5bfa754b209122e 0x8 (alaw) No
Rx: ACK
192.168.9.2 mg0 78d3f4fa2920ac2 0x8 (alaw) No
Rx: ACK
192.168.9.2 mg0 2fcbbb020e2cf0a 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 2cf255430ced865 0x8 (alaw) No
Rx: INVITE
192.168.9.2 mg0 385ac7317e336fc 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 633b90226eaac79 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 36fe9f8b78ce7b2 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 61b9d37358c31de 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 30a1736605b2c28 0x8 (alaw) No
Rx: INVITE
192.168.9.2 mg0 6fe7902c4ae25f0 0x8 (alaw) No
Rx: ACK
192.168.9.2 mg0 7a3168e81aabb71 0x8 (alaw) No
Rx: INVITE
192.168.9.2 mg0 4bf8f6e05a1efc9 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 6665165a33c355e 0x8 (alaw) No
Rx: INVITE
192.168.9.2 mg0 3446ee9b07593d4 0x8 (alaw) No
Rx: ACK
192.168.9.2 mg0 145209e01d8b3d4 0x8 (alaw) No
Tx: ACK
192.168.9.2 mg0 45a79c7c44628cf 0x8 (alaw) No
Rx: INVITE
45 active SIP dialogs
mg0:~#
On this box I have 4xE1 so max I can handle 120 calls.
Before upgrade this MG was rock-stable and had asterisk uptime counted in
weeks.
I have one box running 1.6.1.12 and there seems there is no RTP-UDP ports
problem.
mg0:~# while true
> do
> lsof | grep UDP -c ; sleep 10
> done
682
688
691
682
703
730
745
757
781
^C
mg0:~#
Every few hours I need to restart asterisk as it runs out of free ports
/etc/asterisk/rtp.conf
[general]
rtpstart=5000
rtpend=51000
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0016721 after a few minutes it takes down the s...
======================================================================
----------------------------------------------------------------------
(0117941) fnordian (reporter) - 2010-02-10 07:55
https://issues.asterisk.org/view.php?id=16774#c117941
----------------------------------------------------------------------
I can confirm this issue. In our tests, this happens when an unanswered
call was hung up. Debugging showed an unmatched ao_ref causing the leak.
Here are two ao_ref-debug-traces, the first one shows the old behavior,
the second shows the current one:
0x85df2e8 =1 chan_sip.c:6805:sip_alloc (allocate a dialog(pvt) struct)
0x85df2e8 +1 chan_sip.c:6938:sip_alloc (link pvt into dialogs table)
[@1]
0x820f758 +1 chan_sip.c:4633:find_peer (ao2_find in peers_by_ip table)
[@2]
0x820f758 -1 chan_sip.c:2772:unref_peer (check_peer_ok: unref_peer:
tossing temp ptr to peer from find_peer) [@3]
0x85df2e8 +1 chan_sip.c:6382:sip_new (sip_new: set chan->tech_pvt to i)
[@2]
0x820f758 +1 chan_sip.c:4626:find_peer (ao2_callback in peers table)
[@2]
0x820f758 -1 chan_sip.c:2772:unref_peer (unref peer pointer from
find_peer call in st_get_se (2)) [@3]
0x820f758 +1 chan_sip.c:4626:find_peer (ao2_callback in peers table)
[@2]
0x820f758 -1 chan_sip.c:2772:unref_peer (unref peer pointer from
find_peer call in st_get_mode) [@3]
0x85df2e8 +1 chan_sip.c:3838:update_provisional_keepalive (Increment
refcount to pass dialog pointer to sched callback) [@3]
0x85df2e8 -1 chan_sip.c:21115:handle_request_do (throw away dialog ptr
from find_call at end of routine) [@4]
0x820f758 +1 chan_sip.c:4626:find_peer (ao2_callback in peers table)
[@2]
0x820f758 -1 chan_sip.c:2772:unref_peer (unref_peer, from
sip_devicestate, release ref from find_peer) [@3]
0x85df2e8 -1 chan_sip.c:5690:sip_hangup (unref ast->tech_pvt) [@3]
0x85df2e8 +1 chan_sip.c:3652:sip_scheddestroy (setting ref as passing
into ast_sched_add for __sip_autodestruct) [@2]
0x85df2e8 +1 chan_sip.c:3531:__sip_reliable_xmit (__sip_reliable_xmit:
setting pkt->owner) [@3]
0x85df2e8 +1 chan_sip.c:7058:find_call (ao2_find in dialogs) [@4]
0x85df2e8 -1 chan_sip.c:3730:__sip_ack (unref pkt cur->owner dialog from
sip ack before freeing pkt) [@5]
0x85df2e8 -1 chan_sip.c:21115:handle_request_do (throw away dialog ptr
from find_call at end of routine) [@4]
0x820f758 +1 chan_sip.c:4626:find_peer (ao2_callback in peers table)
[@2]
0x820f758 -1 chan_sip.c:2772:unref_peer (unref_peer, from
sip_devicestate, release ref from find_peer) [@3]
0x85df2e8 +1 chan_sip.c:2820:dialog_unlink_all (Let's bump the count in
the unlink so it doesn't accidentally become dead before we are done) [@3]
0x85df2e8 -1 chan_sip.c:2822:dialog_unlink_all (unlinking dialog via
ao2_unlink) [@4]
0x85df2e8 -1 chan_sip.c:2877:dialog_unlink_all (Let's unbump the count
in the unlink so the poor pvt can disappear if it is time) [@3]
0x85df2e8 -1 chan_sip.c:3631:__sip_autodestruct (The ref to a dialog
passed to this sched callback is going out of scope; unref it.) [@2]
0x82132c8 =1 chan_sip.c:6758:sip_alloc (allocate a dialog(pvt) struct)
0x82132c8 +1 chan_sip.c:6891:sip_alloc (link pvt into dialogs table)
[@1]
0x8242ed0 +1 chan_sip.c:4624:find_peer (ao2_find in peers_by_ip table)
[@2]
0x8242ed0 -1 chan_sip.c:2771:unref_peer (check_peer_ok: unref_peer:
tossing temp ptr to peer from find_peer) [@3]
0x82132c8 +1 chan_sip.c:6335:sip_new (sip_new: set chan->tech_pvt to i)
[@2]
0x8242ed0 +1 chan_sip.c:4617:find_peer (ao2_callback in peers table)
[@2]
0x8242ed0 -1 chan_sip.c:2771:unref_peer (unref peer pointer from
find_peer call in st_get_se (2)) [@3]
0x8242ed0 +1 chan_sip.c:4617:find_peer (ao2_callback in peers table)
[@2]
0x8242ed0 -1 chan_sip.c:2771:unref_peer (unref peer pointer from
find_peer call in st_get_mode) [@3]
0x82132c8 +1 chan_sip.c:3829:update_provisional_keepalive (Increment
refcount to pass dialog pointer to sched callback) [@3]
0x82132c8 -1 chan_sip.c:21039:handle_request_do (throw away dialog ptr
from find_call at end of routine) [@4]
0x8242ed0 +1 chan_sip.c:4617:find_peer (ao2_callback in peers table)
[@2]
0x8242ed0 -1 chan_sip.c:2771:unref_peer (unref_peer, from
sip_devicestate, release ref from find_peer) [@3]
0x82132c8 -1 chan_sip.c:5656:sip_hangup (unref ast->tech_pvt) [@3]
0x82132c8 +1 chan_sip.c:3643:sip_scheddestroy (setting ref as passing
into ast_sched_add for __sip_autodestruct) [@2]
0x82132c8 -1 chan_sip.c:3856:send_response (when you delete the
provisional_keepalive_sched_id, you should dec the refcount for the stored
dialog ptr) [@3]
0x82132c8 +1 chan_sip.c:3528:__sip_reliable_xmit (__sip_reliable_xmit:
setting pkt->owner) [@2]
0x82132c8 +1 chan_sip.c:7011:find_call (ao2_find in dialogs) [@3]
0x82132c8 -1 chan_sip.c:3721:__sip_ack (unref pkt cur->owner dialog from
sip ack before freeing pkt) [@4]
0x82132c8 -1 chan_sip.c:21039:handle_request_do (throw away dialog ptr
from find_call at end of routine) [@3]
0x8242ed0 +1 chan_sip.c:4617:find_peer (ao2_callback in peers table)
[@2]
0x8242ed0 -1 chan_sip.c:2771:unref_peer (unref_peer, from
sip_devicestate, release ref from find_peer) [@3]
0x82132c8 +1 chan_sip.c:2817:dialog_unlink_all (Let's bump the count in
the unlink so it doesn't accidentally become dead before we are done) [@2]
0x82132c8 -1 chan_sip.c:2819:dialog_unlink_all (unlinking dialog via
ao2_unlink) [@3]
0x82132c8 -1 chan_sip.c:2874:dialog_unlink_all (Let's unbump the count
in the unlink so the poor pvt can disappear if it is time) [@2]
0x82132c8 -1 chan_sip.c:3622:__sip_autodestruct (The ref to a dialog
passed to this sched callback is going out of scope; unref it.) [@1]
0x82132c8 **call destructor** chan_sip.c:3622:__sip_autodestruct (The ref
to a dialog passed to this sched callback is going out of scope; unref
it.)
You can see that trace two lacks the unref of send_response(). The
function does not call dialog_unref, because
p->provisional_keepalive_sched_id is already -1.
We walked through svn and found out, that revision 234533 introduced a
change in sip_hangup that set the sched_id to -1. Reverting seems to fix
the problem, but we haven't tested it fully. We also did not investigate in
the issue of rev 234533, so I guess that the problem of 183 after hangup
will occur after revert.
Hope that helps.
Issue History
Date Modified Username Field Change
======================================================================
2010-02-10 07:55 fnordian Note Added: 0117941
======================================================================
More information about the asterisk-bugs
mailing list