aboutsummaryrefslogtreecommitdiffstats
path: root/apps/app_chanspy.c
AgeCommit message (Collapse)AuthorFilesLines
2008-08-20Fix a crash in the ChanSpy application. The issue here is that if you callrussell1-2/+2
ChanSpy and specify a spy group, and sit in the application long enough looping through the channel list, you will eventually run out of stack space and the application with exit with a seg fault. The backtrace was always inside of a harmless snprintf() call, so it was tricky to track down. However, it turned out that the call to snprintf() was just the biggest stack consumer in this code path, so it would always be the first one to hit the boundary. (closes issue #13338) Reported by: ruddy git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139213 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-19Add a lock and unlock prior to the destruction of the chanspy_dsmmichelson1-0/+2
lock to ensure that no other threads still have it locked. While this should not happen under normal circumstances, it appears that if the spyer and spyee hang up at nearly the same time, the following may occur. 1. ast_channel_free is called on the spyee's channel. 2. The chanspy datastore is removed from the spyee's channel in ast_channel_free. 3. In the spyer's thread, the spyer attempts to remove and destroy the datastore from the spyee channel, but the datastore has already been removed in step 2, so the spyer continues in the code. 4. The spyee's thread continues and calls the datastore's destroy callback, chanspy_ds_destroy. This involves locking the chanspy_ds. 5. Now the spyer attempts to destroy the chanspy_ds lock. The problem is that in step 4, the spyee has locked this lock, meaning that the spyer is attempting to destroy a lock which is currently locked by another thread. The backtrace provided in issue #12969 supports the idea that this is possible (and has even occurred). This commit does not close the issue, but should help in preventing one type of crash associated with the use of app_chanspy. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138886 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-23make some more changes to the dahdi/zap channel name support stuff to ensure ↵kpfleming1-8/+5
allthe globals are 'const', and clean up mmichelson's changes to app_chanspy to simplify the code git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@133226 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-23As suggested by seanbright, the PSEUDO_CHAN_LEN in mmichelson1-6/+9
app_chanspy should be set at load time, not at compile time, since dahdi_chan_name is determined at load time. Also changed the next_unique_id_to_use to have the static qualifier. Also added the dahdi_chan_name_len variable so that strlen(dahdi_chan_name) isn't necessary. Thanks to seanbright for the suggestion. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@133169 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-23Zap/pseudo is ten characters, but DAHDI/pseudo ismmichelson1-1/+10
twelve. The strncmp call in next_channel should account for this. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@133104 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-23Update the "last" channel in next_channel in app_chanspy sommichelson1-0/+1
that the same pseudo channel isn't constantly returned. related to issue #13124 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@133101 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-12Adds DAHDI support alongside Zaptel. DAHDI usage favored, but all Zap stuff ↵jpeeler1-1/+3
should continue working. Release announcement to follow. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@122314 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-27Russell noted to me that in the case that separate threads use theirmmichelson1-7/+6
own addressing system, the fix I made for issue 12376 does not guarantee uniqueness to the datastores' uids. Though I know of no system that works this way, I am going to change this right now to prevent trying to track down some future bug that may occur and cause untold hours of debugging time to track down. The change involves using a global counter which increases with each new chanspy_ds which is created. This guarantees uniqueness. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@118509 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-27Add a unique id to the datastore allocated in app_chanspy sincemmichelson1-2/+7
it is possible that multiple spies may be listening to the same channel. (closes issue #12376) Reported by: DougUDI Patches: 12376_chanspy_uid.diff uploaded by putnopvut (license 60) Tested by: destiny6628 (closes issue #12243) Reported by: atis git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@118365 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-25Move the unlock of the spyee channel to outside the start_spying() function ↵mmichelson1-7/+6
so that the channel is not unlocked twice when using whisper mode. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114662 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-23Fix an issue that caused getting the correct next channel to not always work.russell1-5/+3
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: http://svn.digium.com/svn/asterisk/branches/1.4@114597 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-17Declaration of the peer channel in this scope was making it so the peer ↵mmichelson1-1/+0
variable defined 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: http://svn.digium.com/svn/asterisk/branches/1.4@114226 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-17Make sure we have enough room for the recording's filename.seanbright1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114191 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-19Add a missing unlock in the case that memory allocation fails in app_chanspy.mmichelson1-4/+3
Thanks to Russell for confirming that this was an issue. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@110083 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-18Fix one place where the chanspy datastore isn't removed from a channel.russell1-1/+3
(issue #12243, reported by atis, patch by me) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109763 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-17Make sure that we release the lock on the spyee channel if the spyee or spy ↵mmichelson1-1/+3
has hung up (closes issue #12232) Reported by: atis git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109012 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-13Fix another issue that was causing crashes in chanspy. This introduces a newrussell1-0/+10
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: http://svn.digium.com/svn/asterisk/branches/1.4@108583 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-12(closes issue #12187, reported by atis, fixed by me after some brainstormingrussell1-1/+3
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: http://svn.digium.com/svn/asterisk/branches/1.4@108135 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-07Safely use the strncat() function.tilghman1-1/+1
(closes issue #11958) Reported by: norman Patches: 20080209__bug11958.diff.txt uploaded by Corydon76 (license 14) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@106552 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-27Don't loop around infinitely trying to spy on our own channel, and don't ↵file1-5/+5
forget to free/detach the datastore upon hangup of the spy. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104787 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-27Fix a problem in ChanSpy where it could get stuck in an infinite loop withoutrussell1-1/+7
being able to detect that the calling channel hung up. (closes issue #12076, reported by junky, patched by me) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104625 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-27Avoid some recursion in the cleanup code for the chanspy datastorerussell1-0/+2
(closes issue #12076, reported by junky, patched by me) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104334 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-25This patch fixes some pretty significant problems with how app_chanspy handlesrussell1-32/+178
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: http://svn.digium.com/svn/asterisk/branches/1.4@104106 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-23ChanSpy issues a beep when it starts at the beginning of a list of channels torussell1-2/+5
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: http://svn.digium.com/svn/asterisk/branches/1.4@99923 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-16Replace current spy architecture with backport of audiohooks. This should ↵file1-107/+47
take care of current known spy issues. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@98972 f38db490-d61c-443f-a65b-d21fe96a405b
2007-07-13Merged revisions 75066 via svnmerge from mmichelson1-2/+4
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: http://svn.digium.com/svn/asterisk/branches/1.4@75078 f38db490-d61c-443f-a65b-d21fe96a405b
2007-07-05Merged revisions 73349 via svnmerge from file1-1/+2
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r73349 | file | 2007-07-05 11:19:14 -0300 (Thu, 05 Jul 2007) | 2 lines Tweak spy locking. (issue #9951 reported by welles) ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@73355 f38db490-d61c-443f-a65b-d21fe96a405b
2006-11-10Only split up extension and context if a value exists. (issue #8332 reported ↵file1-1/+2
by loloski) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@47437 f38db490-d61c-443f-a65b-d21fe96a405b
2006-10-13Merged revisions 45060 via svnmerge from file1-0/+15
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r45060 | file | 2006-10-13 13:01:22 -0400 (Fri, 13 Oct 2006) | 2 lines Turn on volume adjustment if it needs to be on (issue #8136 reported by mnicholson) ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@45066 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-26Slight overhaul of the whisper support. 1. We need to duplicate the frame ↵file1-0/+5
from ast_translate 2. We need to ensure we always have signed linear coming in for signed linear combining. 3. We need to ensure we are always feeding signed linear out. 4. Properly store and restore write format when beeping on the channel we are whispering on. 5. Properly discontinue the stream on the channel for the beep. (issue #8019 reported by timkelly1980) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@43695 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-05Minor tweak - we need to lock the channel when we are removing the spy from it.file1-0/+2
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@42021 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-03Use tabs instead of spaces (I <3 tabs -- this is for you Qwell)file1-4/+4
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@41960 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-03Make the difference clear about what the responsibilities of the core and a ↵file1-20/+11
spy are when it comes to spying on a channel. The core is responsible for adding a spy to a channel, feeding frames into the spy, removing the spy from the channel, and notifying the spy that is has been detached. The spy is responsible for reading frames in, and cleaning itself up. Each side will not try to do the other's job. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@41959 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-03 We don't spy on Zap/psuedo channels. Not at all. Never. (#7871 - sxpert ↵bweschke1-1/+5
reporting) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@41850 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-21merge new_loader_completion branch, including (at least):kpfleming1-25/+12
- 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: http://svn.digium.com/svn/asterisk/trunk@40722 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-05suppress a compiler warning about the usage of a potentially uninitializedrussell1-1/+1
variable git-svn-id: http://svn.digium.com/svn/asterisk/trunk@39014 f38db490-d61c-443f-a65b-d21fe96a405b
2006-07-28play a beep tone into the spied-on channel if we are about to whisper to themkpfleming1-3/+16
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@38466 f38db490-d61c-443f-a65b-d21fe96a405b
2006-07-28add ExtenSpy variant of ChanSpykpfleming1-56/+211
implement whisper mode for ExtenSpy/ChanSpy git-svn-id: http://svn.digium.com/svn/asterisk/trunk@38465 f38db490-d61c-443f-a65b-d21fe96a405b
2006-07-27more simplification, and correct a bug i introduced in the last commitkpfleming1-18/+18
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: http://svn.digium.com/svn/asterisk/trunk@38389 f38db490-d61c-443f-a65b-d21fe96a405b
2006-07-27remove local channel finding wrapperskpfleming1-117/+111
move guts of dialplan application into separate function, so it can be shared bythe new application i'm about to add :-) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@38374 f38db490-d61c-443f-a65b-d21fe96a405b
2006-07-27restore infinite timeout for ast_waitfor() callkpfleming1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@38369 f38db490-d61c-443f-a65b-d21fe96a405b
2006-07-27various cleanups:kpfleming1-224/+201
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: http://svn.digium.com/svn/asterisk/trunk@38368 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-14Merged revisions 34087 via svnmerge from kpfleming1-1/+2
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r34087 | kpfleming | 2006-06-14 09:07:53 -0500 (Wed, 14 Jun 2006) | 2 lines clarify file headers that mention disclaimer usage ........ git-svn-id: http://svn.digium.com/svn/asterisk/trunk@34090 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-07simplify autoconfig include mechanism (make tholo happy he can use lint ↵kpfleming1-4/+4
again :-) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@32846 f38db490-d61c-443f-a65b-d21fe96a405b
2006-05-10use the channel lock wrappers (issue #7120, Mithraen)russell1-4/+4
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@26528 f38db490-d61c-443f-a65b-d21fe96a405b
2006-05-09Make menuselect be able to show what the modules aremarkster1-3/+3
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@25929 f38db490-d61c-443f-a65b-d21fe96a405b
2006-05-03Allow channels in ChanSpy to belong to mutiple spygroups #7072 (anthm)bweschke1-7/+23
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@24636 f38db490-d61c-443f-a65b-d21fe96a405b
2006-05-01remove an extra newline, none of the other synopsis fields for apps have onerussell1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@23852 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-14This rather large commit changes the way modules are loaded. rizzo1-11/+7
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: http://svn.digium.com/svn/asterisk/trunk@20003 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-08since the module API is changing, it's a good time to const-ify the ↵kpfleming1-2/+2
description() and key() return values git-svn-id: http://svn.digium.com/svn/asterisk/trunk@18552 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 17:56:20 +0000