[asterisk-bugs] [Asterisk 0012736]: core dumped while handling request bye
noreply at bugs.digium.com
noreply at bugs.digium.com
Wed May 28 07:41:42 CDT 2008
The following issue has been RESOLVED.
======================================================================
http://bugs.digium.com/view.php?id=12736
======================================================================
Reported By: laube
Assigned To: file
======================================================================
Project: Asterisk
Issue ID: 12736
Category: Channels/chan_sip/Transfers
Reproducibility: always
Severity: minor
Priority: normal
Status: resolved
Asterisk Version: 1.4.16.2
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
Resolution: suspended
Fixed in Version:
======================================================================
Date Submitted: 05-28-2008 05:36 CDT
Last Modified: 05-28-2008 07:41 CDT
======================================================================
Summary: core dumped while handling request bye
Description:
Every time my sip client (self written) hangs up by "BYE" request I get a
core dump in asterisk. The Last Message that runs through the console is:
NOTICE[18097]: chan_sip.c:14681 handle_request_bye: Client '192.168.0.34'
using deprecated BYE/Also transfer method. Ask vendor to support REFER
instead
The problem is that we did tests with Refer which did not lead to the
expected result we got with BYE. Apart from that such a problem with
BYE/Refer should not crash my asterisk, should it?
Doing a "bt full" in gdb shows that:
(gdb) bt full
http://bugs.digium.com/view.php?id=0 0xb6327402 in handle_request_bye
(p=0x8233098, req=0xb630cfc8) at
strings.h:168
audioqos = <value optimized out>
videoqos = <value optimized out>
c = <value optimized out>
bridged_to = <value optimized out>
__PRETTY_FUNCTION__ = "handle_request_bye"
http://bugs.digium.com/view.php?id=1 0xb6357d51 in handle_request (p=0x8233098,
req=0xb630cfc8,
sin=0xb630e2ec, recount=0x31, nounlock=0xb630e304) at chan_sip.c:15229
__zz__ = 0x81433e0 ""
__dlen__ = <value optimized out>
tag =
"1920668428\0009c18999dcdfc7-67eX?0?\204?6??????\"?WR3?\000\000\000\000H?0?D?0??)3?H?6?@?6?\030_!\b%\000\000\000h\n6??\\!\b\000\000\000\000t\236\225N??5?6\002\000\000\000?6?\030P\035\b\200?6?@?6???6?\001\000\000"
cmd = <value optimized out>
cseq = <value optimized out>
useragent = <value optimized out>
seqno = 103
len = <value optimized out>
ignore = 0
respid = <value optimized out>
res = <value optimized out>
debug = 0
e = 0xb630d1e8 "sip:1 at 192.168.0.34:6080"
__PRETTY_FUNCTION__ = "handle_request"
http://bugs.digium.com/view.php?id=2 0xb6359ce4 in sipsock_read (id=0x81bf490,
fd=18, events=1, ignore=0x0)
at chan_sip.c:15368
req = {rlPart1 = 0xb630d1e4 "BYE", rlPart2 = 0xb630d1e8
"sip:1 at 192.168.0.34:6080", len = 371, headers = 8, method = 8, lines = 0,
flags = 0,
header = {0xb630d1e4 "BYE", 0xb630d209 "Via: SIP/2.0/UDP
192.168.0.34:6080;branch=z9hG4bK011a2eef8e88",
0xb630d248 "To: \"03034507745\"
<sip:03034507745 at 192.168.0.75:5060>tag=as0f67e7d8", 0xb630d28d "From: \"1\"
<sip:1 at 192.168.0.34:6080>;tag=1920668428",
0xb630d2c1 "Contact: sip:1 at 192.168.0.34:6080", 0xb630d2e3 "Call-ID:
6f8bd6c423106dee265950a55e78c0c2 at 192.168.0.75", 0xb630d31b "CSeq: 103 BYE",
0xb630d32a "Also: <sip:03034507736 at 192.168.0.75:5060>", 0xb630d355 "",
0x0 <repeats 55 times>}, line = {0xb630d357 "", 0x0 <repeats 63 times>},
data = "BYE\000sip:1 at 192.168.0.34:6080\000SIP/2.0\000\000Via:
SIP/2.0/UDP 192.168.0.34:6080;branch=z9hG4bK011a2eef8e88\000\000To:
\"03034507745\"
<sip:03034507745 at 192.168.0.75:5060>tag=as0f67e7d8\000\000From: \"1\"
<sip:1 at 192.168.0.34:6"..., sdp_start = 0, sdp_end = 0}
sin = {sin_family = 2, sin_port = 49175, sin_addr = {s_addr =
570468544}, sin_zero = "\000\000\000\000\000\000\000"}
p = (struct sip_pvt *) 0x8233098
res = <value optimized out>
len = 16
nounlock = 0
recount = 0
lockretry = 100
__PRETTY_FUNCTION__ = "sipsock_read"
http://bugs.digium.com/view.php?id=3 0x080a7484 in ast_io_wait (ioc=0x81bcf38,
howlong=49) at io.c:279
res = 1
x = 0
origcnt = 1
http://bugs.digium.com/view.php?id=4 0xb6353e0a in do_monitor (data=0x0) at
chan_sip.c:15571
res = <value optimized out>
sip = (struct sip_pvt *) 0x0
peer = (struct sip_peer *) 0x0
t = 1211968235
fastrestart = 0
lastpeernum = -1
curpeernum = 26
reloading = 0
---Type <return> to continue, or q <return> to quit---
__PRETTY_FUNCTION__ = "do_monitor"
http://bugs.digium.com/view.php?id=5 0x080f6f30 in dummy_start (data=0x31) at
utils.c:852
_buffer = {__routine = 0x8069750 <ast_unregister_thread>, __arg =
0xb630ebb0, __canceltype = 0, __prev = 0x0}
ret = <value optimized out>
http://bugs.digium.com/view.php?id=6 0xb7f10341 in start_thread () from
/lib/tls/i686/cmov/libpthread.so.0
No symbol table info available.
http://bugs.digium.com/view.php?id=7 0xb7e2e4ee in clone () from
/lib/tls/i686/cmov/libc.so.6
No symbol table info available.
Does that help you in finding the problem? Can I provide you with further
information?
Thanks and Regards,
Christophorus Laube
======================================================================
----------------------------------------------------------------------
file - 05-28-08 07:41
----------------------------------------------------------------------
This issue is fixed in Asterisk 1.4.17 and above.
Issue History
Date Modified Username Field Change
======================================================================
05-28-08 07:41 file Note Added: 0087409
======================================================================
More information about the asterisk-bugs
mailing list