[asterisk-bugs] [Asterisk 0011960]: Call from '' to extension '7104' rejected because extension not found
noreply at bugs.digium.com
noreply at bugs.digium.com
Mon Feb 11 19:44:43 CST 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=11960
======================================================================
Reported By: norman
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 11960
Category: Channels/chan_sip/Interoperability
Reproducibility: random
Severity: crash
Priority: normal
Status: new
Asterisk Version: 1.4.18
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 02-08-2008 22:52 CST
Last Modified: 02-11-2008 19:44 CST
======================================================================
Summary: Call from '' to extension '7104' rejected because
extension not found
Description:
I've had a few of these errors:
[Feb 8 16:35:33] NOTICE[2170]: chan_sip.c:13879 handle_request_invite:
Call from '' to extension '202' rejected because extension not found.
[Feb 8 16:35:49] NOTICE[2170]: chan_sip.c:13879 handle_request_invite:
Call from '' to extension '7104' rejected because extension not found.
And shortly there after, it crashes. I'll enclose my crash report with
DONT_OPTIMIZE. The dead thread is http://bugs.digium.com/view.php?id=11
-1246659664 LWP 18653
Thread 11 (process 18653):
0 0xffffe410 in __kernel_vsyscall ()
No symbol table info available.
1 0xb7fc556e in __lll_mutex_lock_wait () from
/lib/tls/i686/cmov/libpthread.so.0
No symbol table info available.
2 0xb7fc2179 in _L_mutex_lock_141 () from
/lib/tls/i686/cmov/libpthread.so.0
No symbol table info available.
3 0x00000000 in ?? ()
No symbol table info available.
I've traced all of the channels that were in the main channels list, and
all of them seemed normal. One (http://bugs.digium.com/view.php?id=1) was making
an outgoing call, and
waiting on the lock that thread 11 had before it crashed.
My boss dialed 202 and he noted that it died right after that. Is this
really the cause of the crash? If so, what's going on? I do have a dial
plan rule for _2XX and 7104, so it appears to have lost it's context.
======================================================================
----------------------------------------------------------------------
norman - 02-11-08 19:44
----------------------------------------------------------------------
Interesting:
==17698== Thread 45:
==17698== Invalid read of size 4
==17698== at 0x4033024: pthread_mutex_lock (in
/lib/tls/i686/cmov/libpthread-2.3.6.so)
==17698== by 0x80CD666: ast_mutex_lock (lock.h:701)
==17698== by 0x80D3816: p2p_set_bridge (rtp.c:3103)
==17698== by 0x80D4011: bridge_p2p_loop (rtp.c:3242)
==17698== by 0x80D481A: ast_rtp_bridge (rtp.c:3387)
==17698== by 0x8088BF2: ast_channel_bridge (channel.c:3997)
==17698== by 0x58E53ED: ast_bridge_call (res_features.c:1420)
==17698== by 0x675209B: try_calling (app_acd.c:4081)
==17698== by 0x6755E78: handle_acd (app_acd.c:5090)
==17698== by 0x6755532: acd_exec (app_acd.c:4917)
==17698== by 0x80BAE73: pbx_exec (pbx.c:532)
==17698== by 0x80BE23C: pbx_extension_helper (pbx.c:1851)
==17698== Address 0x716ae88 is 8,576 bytes inside a block of size 10,720
free'd
==17698== at 0x401D40C: free (vg_replace_malloc.c:323)
==17698== by 0x80CF634: ast_rtp_destroy (rtp.c:2151)
==17698== by 0x59C551F: __sip_destroy (chan_sip.c:3084)
==17698== by 0x59FF37C: do_monitor (chan_sip.c:15586)
==17698== by 0x80FC35A: dummy_start (utils.c:852)
==17698== by 0x403123F: start_thread (in
/lib/tls/i686/cmov/libpthread-2.3.6.so)
==17698== by 0x4FAF49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so)
It appears the the chan_sip monitor thread is disposing the struct ast_rtp
of when bridge_p2p_loop (after the bridge terminates in a different thread)
thinks it has it. Why is this?
My app_acd is basically app_queue (from 1.4.18) with the realtime stuff
redone and personal (agent-specific) sub-queues.
Our clients make calls in the background on the same SIP account, but that
shouldn't be a problem, assume, since they are different INVITEs.
Issue History
Date Modified Username Field Change
======================================================================
02-11-08 19:44 norman Note Added: 0082060
======================================================================
More information about the asterisk-bugs
mailing list