Also, remove setting the amount of time to wait for a digit from 5 seconds back
down to 1/10 of a second. I believe this was so the beep didn't get played over
and over really fast, but a while back I put in another fix for that issue.
(closes issue #12498)
Reported by: jsmith
Patches:
app_chanspy_channel_walk.trunk.patch uploaded by jsmith (license 15)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114597 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in the outer scope was never set properly, therefore making iterating through the channel
list always restart from the beginning. This bug would have affected anyone who called
chanspy without specifying a first argument.
(closes issue #12461)
Reported by: stever28
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114226 65c4cc65-6c06-0410-ace0-fbb531ad65f3
datastore callback, called chan_fixup(). The concept is exactly like the
fixup callback that is used in the channel technology interface. This callback
gets called when the owning channel changes due to a masquerade. Before this
was introduced, if a masquerade happened on a channel being spyed on, the
channel pointer in the datastore became invalid.
(closes issue #12187)
(reported by, and lots of testing from atis)
(props to file for the help with ideas)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@108583 65c4cc65-6c06-0410-ace0-fbb531ad65f3
on the issue with mmichelson)
- Update copyright info on app_chanspy.
- Fix a race condition that caused app_chanspy to crash. The issue was that
the chanspy datastore magic that was used to ensure that spyee channels did
not disappear out from under the code did not completely solve the problem.
It was actually possible for chanspy to acquire a channel reference out of
its datastore to a channel that was in the middle of being destroyed. That
was because datastore destruction in ast_channel_free() was done near the
end. So, this left the code in app_chanspy accessing a channel that was
partially, or completely invalid because it was in the process of being free'd
by another thread. The following sort of shows the code path where the race
occurred:
=============================================================================
Thread 1 (PBX thread for spyee chan) || Thread 2 (chanspy)
--------------------------------------||-------------------------------------
ast_channel_free() ||
- remove channel from channel list ||
- lock/unlock the channel to ensure ||
that no references retrieved from ||
the channel list exist. ||
--------------------------------------||-------------------------------------
|| channel_spy()
- destroy some channel data || - Lock chanspy datastore
|| - Retrieve reference to channel
|| - lock channel
|| - Unlock chanspy datastore
--------------------------------------||-------------------------------------
- destroy channel datastores ||
- call chanspy datastore d'tor ||
which NULL's out the ds' || - Operate on the channel ...
reference to the channel ||
||
- free the channel ||
||
|| - unlock the channel
--------------------------------------||-------------------------------------
=============================================================================
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@108135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pointers to channels that are being spied upon. It was very likely that a
crash would occur if the channel being spied upon hung up. This was because
the current ast_channel handling _requires_ that the object is locked or else
it could disappear at any time (except in the owning channel thread). So, this
patch uses some channel datastore magic on the spied upon channel to be able to
detect if and when the channel goes away.
(closes issue #11877)
(patch written by me, but thanks to kpfleming for the idea, and to file for review)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@104106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
potentially spy on. However, if there were no matching channels, it would beep
at you over and over, which is pretty annoying. Now, it will only beep once in
the case that there are no channels to spy on, but it will still beep again once
it reaches the beginning of the channel list again.
(closes issue #11738, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@99923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75066 | mmichelson | 2007-07-13 15:10:39 -0500 (Fri, 13 Jul 2007) | 5 lines
Fixed an issue where chanspy flags were uninitialized if no options were passed.
What triggered this investigation was an IRC chat where some people's quiet flags were
set while others' weren't even though none of them had specified the q option.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75078 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- restructured build tree and makefiles to eliminate recursion problems
- support for embedded modules
- support for static builds
- simpler cross-compilation support
- simpler module/loader interface (no exported symbols)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
fix prototype for a channel walking function to use a const input pointer
use existing channel walk by name prefix instead of reproducing that code in this app
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38389 65c4cc65-6c06-0410-ace0-fbb531ad65f3
move guts of dialplan application into separate function, so it can be shared bythe new application i'm about to add :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38374 65c4cc65-6c06-0410-ace0-fbb531ad65f3
use API call for finding channel by name prefix
code formatting to match guidelines (lost about half the of the indenting)
remove useless automatic variable initializations
don't set the spying channel's read format to SLINEAR when we don't do anything with the voice frames we read from it anyway
use proper option argument checking for volume argument
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As partly documented in loader.c and include/asterisk/module.h,
modules are now expected to return all of their methods and flags
into a structure 'mod_data', and are normally loaded with RTLD_NOW
| RTLD_LOCAL, so symbols are resolved immediately and conflicts
should be less likely. Only in a small number of cases (res_*,
typically) modules are loaded RTLD_GLOBAL, so they can export
symbols.
The core of the change is only the two files loader.c and
include/asterisk/module.h, all the rest is simply adaptation of the
existing modules to the new API, a rather mechanical (but believe
me, time and finger-consuming!) process whose detail you can figure
out by svn diff'ing any single module.
Expect some minor compilation issue after this change, please
report it on mantis http://bugs.digium.com/view.php?id=6968
so we collect all the feedback in one place.
I am just sorry that this change missed SVN version number 20000!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@20003 65c4cc65-6c06-0410-ace0-fbb531ad65f3
