[asterisk-bugs] [Asterisk 0018742]: MIXMON_ARGS not processed when call being monitored via chanspy
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Feb 7 14:08:50 CST 2011
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=18742
======================================================================
Reported By: jkister
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 18742
Category: Applications/app_mixmonitor
Reproducibility: always
Severity: major
Priority: normal
Status: feedback
Asterisk Version: 1.8.2.3
JIRA: SWP-3043
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2011-02-03 11:02 CST
Last Modified: 2011-02-07 14:08 CST
======================================================================
Summary: MIXMON_ARGS not processed when call being monitored
via chanspy
Description:
x146 is talking to an outside line
x143 uses extenspy to listen on x146
x146 hangs up the call to outside line (while x143 is still monitoring)
${MIXMON_ARGS} is not honored.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
has duplicate 0018750 The MixMonitor application fails to exe...
======================================================================
----------------------------------------------------------------------
(0131606) jcovert (reporter) - 2011-02-07 14:08
https://issues.asterisk.org/view.php?id=18742#c131606
----------------------------------------------------------------------
It's actually not a "lock" deadlock.
It's trivial to reproduce:
exten => 12649901,1,Goto(ringlocals,s,1)
exten => 12649902,1,MixMonitor(jrctest,,/usr/bin/say MixMonitor done)
exten => 12649902,n,Goto(12649901,1)
exten => 12649903,1,Answer()
exten => 12649903,n,ExtenSpy(s at ringlocals)
[ringlocals]
exten => s,1,Dial(SIP/localsjphone,120)
exten => s,2,Macro(fastbusy)
Example with ExtenSpy **NOT** active
-- Executing [12649902 at inbound-cnet-264:1]
MixMonitor("IAX2/mainpbx-8025", "jrctest,,/usr/bin/say MixMonitor done") in
new stack
== Autochan JRC Created autochan 0x4c5ebd0 to hold channel
IAX2/mainpbx-8025 (0x18d3110)
-- Executing [12649902 at inbound-cnet-264:2] Goto("IAX2/mainpbx-8025",
"12649901,1") in new stack
-- Goto (inbound-cnet-264,12649901,1)
-- Executing [12649901 at inbound-cnet-264:1] Goto("IAX2/mainpbx-8025",
"ringlocals,s,1") in new stack
-- Goto (ringlocals,s,1)
-- Executing [s at ringlocals:1] Dial("IAX2/mainpbx-8025",
"SIP/localsjphone,120") in new stack
== Begin MixMonitor Recording IAX2/mainpbx-8025
-- Called localsjphone
-- SIP/localsjphone-00000000 is ringing
-- SIP/localsjphone-00000000 is ringing
-- SIP/localsjphone-00000000 is ringing
-- SIP/localsjphone-00000000 answered IAX2/mainpbx-8025
== Spawn extension (ringlocals, s, 1) exited non-zero on
'IAX2/mainpbx-8025'
== MixMonitor jrc debug point before call to audiohook_unlock 18d4000
== MixMonitor jrc debug point after call to audiohook_unlock
== Autochan jrc Removed autochan 0x4c5ebd0 from the list, about to free
it
== MixMonitor jrc debug point after call to autochan_destroy
== MixMonitor jrc debug before call to ds_close_fs 18d4000
== MixMonitor close filestream
== (Partial Workaround-moved up) Executing [/usr/bin/say MixMonitor
done]
-- Hungup 'IAX2/mainpbx-8025'
== MixMonitor jrc debug point mixmonitor_ds_destroy entry
== MixMonitor jrc debug point before cond_wait (!destruction_ok)
== MixMonitor jrc debug point mixmonitor_ds_destroy exit
== MixMonitor jrc debug point after cond_wait
== MixMonitor jrc debug point before kill the audiohook
== MixMonitor jrc debug point after kill the audiohook
== End MixMonitor Recording IAX2/mainpbx-8025
== MixMonitor jrc debug point free 18d4000
***
Now, with ExtenSpy running:
-- Executing [12649902 at inbound-cnet-264:1]
MixMonitor("IAX2/mainpbx-485", "jrctest,,/usr/bin/say MixMonitor done") in
new stack
== Autochan JRC Created autochan 0x4c82db0 to hold channel
IAX2/mainpbx-485 (0x18e5310)
-- Executing [12649902 at inbound-cnet-264:2] Goto("IAX2/mainpbx-485",
"12649901,1") in new stack
-- Goto (inbound-cnet-264,12649901,1)
-- Executing [12649901 at inbound-cnet-264:1] Goto("IAX2/mainpbx-485",
"ringlocals,s,1") in new stack
-- Goto (ringlocals,s,1)
-- Executing [s at ringlocals:1] Dial("IAX2/mainpbx-485",
"SIP/localsjphone&SIP/x26&SIP/x27,120") in new stack
-- Called localsjphone
[Feb 7 14:54:01] WARNING[23331]: app_dial.c:2039 dial_exec_full: Unable
to create channel of type 'SIP' (cause 20 - Unknown)
[Feb 7 14:54:01] WARNING[23331]: app_dial.c:2039 dial_exec_full: Unable
to create channel of type 'SIP' (cause 20 - Unknown)
== Begin MixMonitor Recording IAX2/mainpbx-485
== Autochan JRC Created autochan 0x4c83fd0 to hold channel
IAX2/mainpbx-485 (0x18e5310)
-- SIP/localsjphone-00000001 is ringing
-- <IAX2/mainpbx-643> Playing 'spy-iax2.ulaw' (language 'en')
== Spying on channel IAX2/mainpbx-485
[Feb 7 14:54:02] NOTICE[23331]: app_chanspy.c:479 start_spying: Attaching
IAX2/mainpbx-643 to IAX2/mainpbx-485
[Feb 7 14:54:02] NOTICE[23331]: app_chanspy.c:479 start_spying: Attaching
IAX2/mainpbx-643 to IAX2/mainpbx-485
== Spawn extension (ringlocals, s, 1) exited non-zero on
'IAX2/mainpbx-485'
-- Hungup 'IAX2/mainpbx-485'
== MixMonitor jrc debug point before call to audiohook_unlock 18eb000
== MixMonitor jrc debug point after call to audiohook_unlock
== Autochan jrc Removed autochan 0x4c82db0 from the list, about to free
it
== MixMonitor jrc debug point after call to autochan_destroy
== MixMonitor jrc debug before call to ds_close_fs 18eb000
== MixMonitor close filestream
== (Partial Workaround-moved up) Executing [/usr/bin/say MixMonitor
done]
== Done Spying on channel IAX2/mainpbx-485
== Autochan jrc Removed autochan 0x4c83fd0 from the list, about to free
it
-- <IAX2/mainpbx-643> Playing 'beep.ulaw' (language 'en')
== MixMonitor jrc debug point before cond_wait (!destruction_ok)
Note that we are stuck in cond_wait because the destruction condition is
never met, not because a lock is stuck. Note also that each time we called
mixmonitor with ExtenSpy active, we got a new entry for mixmonitor_thread.
jrcovert*CLI> core show threads
0x181b800 mixmonitor_thread started at [ 476] app_mixmonitor.c
launch_monitor_thread()
0x18f8000 mixmonitor_thread started at [ 476] app_mixmonitor.c
launch_monitor_thread()
0x1867800 mixmonitor_thread started at [ 476] app_mixmonitor.c
launch_monitor_thread()
After we drop ExtenSpy, If we call MiXMonitor we get one more:
0x18e4e00 mixmonitor_thread started at [ 476] app_mixmonitor.c
launch_monitor_thread()
But it is removed when this call hangs up (no dead one left behind).
Issue History
Date Modified Username Field Change
======================================================================
2011-02-07 14:08 jcovert Note Added: 0131606
======================================================================
More information about the asterisk-bugs
mailing list