aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2007-11-16Temporarily revert revision 89325, which added md5 magic for keeping track ofrussell1-4/+1
what build options were used. We agreed that we should remove this before making a 1.4 release, and then we can put it back in. Then, we can take a month or so to play around with it to get it how we want it. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89339 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-16To help combat problems where people build external modules (asterisk-addons ↵kpfleming1-1/+4
or others) and then change the build options of the Asterisk build in a way that makes the incompatible without warning, this commit introduces an MD5 signature of the important build-time options and includes that signature into modules when they are built. When the loader loads one of these modules and notices the problem, it will emit a warning to console and refuse to initialize the module, as doing so could cause the system to be unstable or even crash. If you upgrade to this version of Asterisk, you must rebuild *all* of your modules that came from other sources before trying to run this version. If you are using Digium's G.729 binary codec module, you will need v33 or newer. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89325 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-06We went to the trouble of creating a method of tracking failed trylocks, ↵tilghman1-1/+1
then never turned it on (oops). git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89045 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-06Remove some checks to see if locks are initialized from the non-DEBUG_THREADSrussell1-67/+0
versions of the lock routines. These are incorrect for a number of reasons: - It breaks the build on mac. - If there is a problem with locks not getting initialized, then the proper fix is to find that place and fix the code so that it does get initialized. - If additional debug code is needed to help find the problem areas, then this type of things should _only_ be put in the DEBUG_THREADS wrappers. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88931 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-06update comment to match the state of the codekpfleming1-4/+3
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88862 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-05After seeing crashes related to channel variables, I went looking around at therussell1-0/+24
ways that channel variables are handled. In general, they were not handled in a thread-safe way. The channel _must_ be locked when reading or writing from/to the channel variable list. What I have done to improve this situation is to make pbx_builtin_setvar_helper() and friends lock the channel when doing their thing. Asterisk API calls almost all lock the channel for you as necessary, but this family of functions did not. (closes issue #10923, reported by atis) (closes issue #11159, reported by 850t) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88805 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-05Merge changes from asterisk/team/kpfleming/SRV-priority-handlingrussell1-3/+4
Previously, the SRV record support in Asterisk was broken. There was no guarantee on what record Asterisk would choose to actually use. This set of changes improves the situation by ensuring that Asterisk will choose the highest priority record. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88719 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-04Rename ast_string_field_free_pool to ast_string_field_free_memory,rizzo1-3/+3
and ast_string_field_free_all to ast_string_field_reset_all to avoid misuse (due to too similar names and an error in documentation). Fix two related memory leaks in app_meetme. No need to merge to trunk, different fix already applied there. Not applicable to 1.2 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88471 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-02Fix build on Solaristilghman1-29/+29
Reported by: snuffy Patch by: ys Closes issue #11143 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88210 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-30Fix for uninitialized mutexes on *BSDtilghman1-67/+298
Reported by: ys Fixed by: ys Closes issue #11116 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@87739 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-29Add some more details to the output of "core show locks". When a threadrussell1-24/+24
is waiting for a lock, this will now show the details about who currently has it locked. (inspired by issue #11100) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@87396 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-26closes issue #11086 where a user complains that references to following ↵murf1-1/+2
contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config, git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@87168 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-25appending one list to another should leave the first list empty, and not ↵kpfleming1-0/+5
require the user to do that git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@87069 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-22If lock tracking is not enabled, then we can not attempt to log any mutexrussell1-4/+19
failures. If so, we could end up in infinite recursion. The only lock that is affected by this is a mutex in astmm.c used when MALLOC_DEBUG is enabled. (closes issue #11044) Reported by: ys Patches: lock.h.diff uploaded by ys (license 281) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@86836 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-22Update the static mutex initializer to include the initialization ofrussell1-2/+2
the internal mutex used to protect the lock debugging data. (closes issue #11044, patch suggested by Ivan) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@86726 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-18The channel needs to stay locked while running timer callbacks, as they accessrussell1-0/+1
and modify channel data that may change elsewhere. I went through every timer callback in the source tree to make sure that none of them did any additional locking that could introduce deadlocks, and all is well. (closes issue #10765) Reported by: Ivan Patches: ast_1_4_11_svn_patch_channel_rc.diff uploaded by Ivan (license 229) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@86330 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-16really picky formatting tweak ...russell1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85997 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-16Some locking errors exposed the fact that the lock debugging code itself wasrussell1-19/+71
not thread safe. How ironic! Anyway, these changes ensure that the code that is accessing the lock debugging data is thread-safe. Many thanks to Ivan for finding and fixing the core issue here, and also thanks to those that tested the patch and provided test results. (closes issue #10571) (closes issue #10886) (closes issue #10875) (might close some others, as well ...) Patches: (from issue #10571) ivan_ast_1_4_12_rel_patch_lock.h.diff uploaded by Ivan (license 229) - a few small changes by me git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85994 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-15Make a few changes so that characters in the upper half of the ISO-8859-1russell1-3/+3
character set don't get stripped when reading configuration. (closes issue #10982, dandre) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85561 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-13Fix an issue with console verbosity when running asterisk -rx to execute a ↵russell1-1/+1
command and retrieve its output. The issue was that there was no way for the main Asterisk process to know that the remote console was connecting in the -rx mode. The way that James has fixed this is to have all remote consoles muted by default. Then, regular remote consoles automatically execute a CLI command to unmute themselves when they first start up. (closes issue #10847) Reported by: atis Patches: asterisk-consolemute.diff.txt uploaded by jamesgolovich (license 176) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85533 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-13Properly handle the case where read() may return the text for more than onerussell1-0/+8
CLI command at once for a remote console. (closes issue #10888) Reported by: jamesgolovich Patches: asterisk-climultiple.diff.txt uploaded by jamesgolovich (license 176) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85532 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-10I introduced a new member to the ast_filestream struct in 1.4.12, but put itrussell1-1/+1
in the middle of the struct, instead of at the end. One of the Debian folks, paravoid, pointed out that this breaks binary compatability with modules compiled against older headers. So, I'm moving the new member to the end of the struct to resolve the situation. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85316 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-10use a macro instead of an inline function, so that backtraces will report ↵kpfleming1-4/+1
the caller of ast_frame_free() properly git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85195 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-09This commit fixes the following issues:tilghman1-4/+12
- Deadlock in ast_write (issue #10406) - Deadlock in ast_read (issue #10406) - Possible mutex initialization error in lock.h (issue #10571) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85158 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-01Fulfull a feature request from Qwell on the "core show locks" output. It willrussell1-10/+17
now note the lock type for each lock that a thread holds. (mutex, rdlock, or wrlock) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84271 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-01Show rwlocks in the "core show locks" output. Before, it only showed mutexes.russell1-0/+79
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84206 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-30Fix the AST_MODULE_INFO macro for C++ modules. The load and reload parametersrussell1-1/+1
were in the wrong place. (closes issue #10846, alebm) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84146 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-27if an Agent is redirected, the base channel should actually be redirected. ↵dhubbard1-0/+6
This was causing multiple issues, especially issue 7706 and BE-160 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84018 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-21gcc 4.2 has a new set of warnings dealing with cosnt pointers. This set ofrussell2-5/+5
changes gets all of Asterisk (minus chan_alsa for now) to compile with gcc 4.2. (closes issue #10774, patch from qwell) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@83432 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-18Add a new patch to handle interrupting the fgets() call when using FastAGI.russell1-0/+1
This version of the patch maintains the original behavior of the code when not using FastAGI. (closes issue #10553) Reported by: juggie Patches: res_agi_fgets-4.patch uploaded by juggie (license 24) res_agi_fgets_1.4svn.patch uploaded by juggie (license 24) Slight mods by me Tested by: juggie, festr git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@82929 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-14Add checking for libusb here, so nobody has to deal with conflicts in therussell1-0/+3
chan_usbradio-1.4 branch every time the configure script gets changed git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@82385 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-13Only compile in tracking astobj2 statistics if dev-mode is enabled. Also, whenrussell1-0/+1
dev mode is enabled, register the CLI command that can be used to run the astobj2 test and print out statistics. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@82337 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-12Working on issue #10531 exposed a rather nasty 64-bit issue on ast_mktime, so wetilghman1-4/+0
updated the localtime.c file from source. Next we'll have to write ast_strptime to match. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@82285 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-09Fix inline compiles on really old compilers (who uses gcc 2.7 anymore, really?)tilghman1-3/+11
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@82028 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-06This should fix a build issue that people building against uClibc were ↵qwell1-2/+0
seeing with the addition of astobj2 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@81778 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-06Various string length fixes. Removed an unused variable in aji_client ↵phsultan1-5/+17
structure (context) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@81743 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-05Fix an issue that can occur when you do an attended transfer to parking. Ifrussell2-0/+4
you complete the transfer before the announcement of the parking spot finishes, then the channel being parked will hear the remainder of the announcement. These changes make it so that will not happen anymore. Basically, res_features sets a flag on the channel is playing the announcement to so that the file streaming core knows that it needs to watch out for a channel masquerade, and if it occurs, to abort the announcement. (closes BE-182) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@81599 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-05Solaris x86 compatibility fixtilghman1-0/+4
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@81569 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-04Remove the typedefs on ao2_container and ao2_iterator. This is simply becauserussell1-25/+17
we don't typedef objects anywhere else in Asterisk, so we might as well make this follow the same convention. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@81448 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-01Making match_by_addr into ao2_match_by_addr and making it availablemmichelson1-0/+1
everywhere since it could be a handy callback to have git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@81426 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-31Remove references to a debugging parameter that does not existrussell1-2/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@81418 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-23When executing a dynamic feature, don't look it up a second time by digit ↵russell1-1/+1
pattern after we already looked it up by name. This causes broken behavior if there is more than one feature defined with the same digit pattern. (closes issue #10539, reported by bungalow, patch by me) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@80573 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-23This is a hack to maintain old behavior of chan_iax2. This ensures that ifrussell1-1/+8
the peers and users are being stored in a linked list, that they go in the list in the same order that the older code used. This is necessary to maintain the behavior of which peers and users get matched when traversing the container. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@80497 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-22Add some more documentation on iterating ao2 containers. The documentationrussell1-33/+45
implies that is possible to miss an object or see an object twice while iterating. After looking through the code and talking with mmichelson, I have documented the exact conditions under which this can happen (which are rare and harmless in most cases). git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@80426 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-22Merge changes from team/russell/iax_refcount.russell2-0/+534
This set of changes fixes problems with the handling of iax2_user and iax2_peer objects. It was very possible for a thread to still hold a reference to one of these objects while a reload operation tries to delete them. The fix here is to ensure that all references to these objects are tracked so that they can't go away while still in use. To accomplish this, I used the astobj2 reference counted object model. This code has been in one of Luigi Rizzo's branches for a long time and was primarily developed by one of his students, Marta Carbone. I wanted to go ahead and bring this in to 1.4 because there are other problems similar to the ones fixed by these changes, so we might as well go ahead and use the new astobj if we're going to go through all of the work necessary to fix the problems. As a nice side benefit of these changes, peer and user handling got more efficient. Using astobj2 lets us not hold the container lock for peers or users nearly as long while iterating. Also, by changing a define at the top of chan_iax2.c, the objects will be distributed in a hash table, drastically increasing lookup speed in these containers, which will have a very big impact on systems that have a large number of users or peers. The use of the hash table will be made the default in trunk. It is not the default in 1.4 because it changes the behavior slightly. Previously, since peers and users were stored in memory in the same order they were specified in the configuration file, you could influence peer and user matching order based on the order they are specified in the configuration. The hash table does not guarantee any order in the container, so this behavior will be going away. It just means that you have to be a little more careful ensuring that peers and users are matched explicitly and not forcing chan_iax2 to have to guess which user is the right one based on secret, host, and access list settings, instead of simply using the username. If you have any questions, feel free to ask on the asterisk-dev list. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@80362 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-21ugh. removing the diffs from ulaw.h and alaw.h for now; accidentally added ↵murf2-99/+1
them in 80166 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@80167 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-21This patch solves problem 1 in 8126; it should not slow down the alaw codec, ↵murf2-1/+99
but should prevent signal degradation via multiple trips thru the codec. Fossil estimates the twice thru this codec will prevent fax from working. 4-6 times thru would result hearable, noticeable, voice degradation. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@80166 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-17Don't send a semicolon over the wire in sip notify messages.qwell1-0/+7
Caused by fix for issue 9938. I basically took the code that existed before 9938 was fixed, and copied it into a new function - ast_unescape_semicolon There should be very few places this will be needed (pbx_config does NOT need this (see issue 9938 for details)) Issue 10430, patch by me, with help/ideas from murf (thanks murf). git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@79904 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-13Instead of accepting a single DTMF character accept a full string.file1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@79334 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-13Add an API call to allow the engine to know that DTMF was received.file1-0/+4
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@79207 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-09 21:55:29 +0000