aboutsummaryrefslogtreecommitdiffstats
path: root/main/utils.c
AgeCommit message (Collapse)AuthorFilesLines
2011-01-11Prevent buffer overflows in ast_uri_encode()mnicholson1-14/+13
ABE-2705 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@301305 f38db490-d61c-443f-a65b-d21fe96a405b
2010-12-17Let Asterisk find better backtrace information with libbfd.tilghman1-0/+20
The menuselect option BETTER_BACKTRACES, if enabled, will use libbfd to search for better symbol information within both the Asterisk binary, as well as loaded modules, to assist when using inline backtraces to track down problems. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@298905 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-20Resolve a number of FreeBSD build issues.russell1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@253631 f38db490-d61c-443f-a65b-d21fe96a405b
2010-01-05Change a NOTICE log message to DEBUG where it belongs.russell1-1/+3
(closes issue #16479) Reported by: alexrecarey (closes SWP-577) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@237697 f38db490-d61c-443f-a65b-d21fe96a405b
2009-12-07hex escape control and non 7-bit clean characters in uri_encodedvossel1-1/+1
In ast_uri_encode, non 7-bit clean characters were being hex escaped correctly, but control characters were not. (issue #16299) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@233609 f38db490-d61c-443f-a65b-d21fe96a405b
2009-11-06Properly handle '=' while decoding base64 messages and null terminate ↵mnicholson1-1/+1
strings returned from BASE64_DECODE. (closes issue #15271) Reported by: chappell Patches: base64_fix.patch uploaded by chappell (license 8) Tested by: kobaz git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@228378 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-04make asterisk compile under devmode with DEBUG_THREADS enabled on OpenBSDmvanbaak1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216435 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-10AST-2009-005tilghman1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211528 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-18Fix cases where the internal poll() was not being used when it needed to be.russell1-2/+2
We have seen a number of problems caused by poll() not working properly on Mac OSX. If you search around, you'll find a number of references to using select() instead of poll() to work around these issues. In Asterisk, we've had poll.c which implements poll() using select() internally. However, we were still getting reports of problems. vadim investigated a bit and realized that at least on his system, even though we were compiling in poll.o, the system poll() was still being used. So, the primary purpose of this patch is to ensure that we're using the internal poll() when we want it to be used. The changes are: 1) Remove logic for when internal poll should be used from the Makefile. Instead, put it in the configure script. The logic in the configure script is the same as it was in the Makefile. Ideally, we would have a functionality test for the problem, but that's not actually possible, since we would have to be able to run an application on the _target_ system to test poll() behavior. 2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT is not defined. 3) Change uses of poll() throughout the source tree to ast_poll(). I feel that it is good practice to give the API call a new name when we are changing its behavior and not using the system version directly in all cases. So, normally, ast_poll() is just redefined to poll(). On systems where AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll(). 4) Change poll() in main/poll.c to be ast_internal_poll(). It's worth noting that any code that still uses poll() directly will work fine (if they worked fine before). So, for example, out of tree modules that are using poll() will not stop working or anything. However, for modules to work properly on Mac OSX, ast_poll() needs to be used. (closes issue #13404) Reported by: agalbraith Tested by: russell, vadim http://reviewboard.digium.com/r/198/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@182810 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-18Merged revisions 177035 manually from dbailey1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r177035 | dbailey | 2009-02-18 11:24:07 -0600 (Wed, 18 Feb 2009) | 2 lines Fixed error where a check for an zero length, terminated string was needed. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177039 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-18Need to take into account the \0 terminator of the old string to determine ↵dbailey1-1/+1
the amount available. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176945 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-16correct a logic error in the last stringfields commit... don't mark ↵kpfleming1-3/+5
additional space as allocated if the string was built using already-allocated space git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176254 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-16fix a flaw in the ast_string_field_build() family of API calls; these ↵kpfleming1-11/+36
functions made no attempt to reuse the space already allocated to a field, so every time the field was written it would allocate new space, leading to what appeared to be a memory leak. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176216 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-22Fix up timeout handling in ast_carefulwrite().russell1-1/+18
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166297 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-18Make ast_carefulwrite() be more careful.russell1-13/+38
This patch handles some additional cases that could result in partial writes to the file description. This was done to address complaints about partial writes on AMI. (issue #13546) (more changes needed to address potential problems in 1.6) Reported by: srt Tested by: russell Review: http://reviewboard.digium.com/r/99/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165796 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-16Fix an issue where DEBUG_THREADS may erroneously report that a thread russell1-0/+6
is exiting while holding a lock. If the last lock attempt was a trylock, and it failed, it will still be in the list of locks so that it can be reported. (closes issue #13219) Reported by: pj git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@164881 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09Remove the test_for_thread_safety() function completely.russell1-62/+0
The test is not valid. Besides, if we actually suspected that recursive mutexes were not working, we would get a ton of LOG_ERROR messages when DEBUG_THREADS is turned on. (inspired by a discussion on the asterisk-dev list) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162413 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-03somehow missed a bunch of gcc 4.3.x warnings in this branch on the first passkpfleming1-2/+5
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@153823 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-23revert an optimization that broke ABI... thanks russell!kpfleming1-26/+0
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@133237 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-23minor optimization for stringfields: when a field is being set to a larger ↵kpfleming1-2/+28
value than it currently contains and it happens to be the most recent field allocated from the currentl pool, it is possible to 'grow' it without having to waste the space it is currently using (or potentially even allocate a new pool) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@132872 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-27In this debugging function, copy to a buffer instead of using potentially ↵tilghman1-4/+4
unsafe pointers. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@125793 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-26Make sure to unlock the lock_info lock (huh?). Possible deadlock?qwell1-0/+3
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@125587 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-19Merge revision 124064 from trunk. Add errors that report any locks held by ↵bbryant1-0/+14
threads when they are being closed. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@124066 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29Add some debugging code that ensures that when we do deadlock avoidance, wetilghman1-0/+28
don't lose the information about how a lock was originally acquired. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@118953 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-23Don't declare a function that takes variable arguments as inline, because it'srussell1-0/+14
not valid, and on some compilers, will emit a warning. http://gcc.gnu.org/onlinedocs/gcc/Inline.html#Inline (closes issue #12289) Reported by: francesco_r Patches by Tilghman, final patch by me git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@118048 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-12If a thread holds no locks, do not print any information on the thread when ↵mmichelson1-38/+40
issuing a core show locks command. This will help to de-clutter output somewhat. Russell said it would be fine to place this improvement in the 1.4 branch, so that's why it's going here too. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115735 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-01'#' is another reserved character for URIs that also needs to be escaped.tilghman1-1/+1
(closes issue #10543) Reported by: blitzrage Patches: 20080418__bug10543.diff.txt uploaded by Corydon76 (license 14) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115017 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-10Fix 1.4 build when LOW_MEMORY is enabled.mmichelson1-0/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114051 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-19Tweak spacing in a recent change because I'm very picky.russell1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109838 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-17Fix a logic flaw in the code that stores lock info which is displayedmmichelson1-1/+1
via the "core show locks" command. The idea behind this section of code was to remove the previous lock from the list if it was a trylock that had failed. Unfortunately, instead of checking the status of the previous lock, we were referencing the index immediately following the previous lock in the lock_info->locks array. The result of this problem, under the right circumstances, was that the lock which we currently in the process of attempting to acquire could "overwrite" the previous lock which was acquired. While this does not in any way affect typical operation, it *could* lead to misleading "core show locks" output. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109226 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-28Fix a bug in the lock tracking code that was discovered by mmichelson. The ↵russell1-5/+9
issue is that if the lock history array was full, then the functions to mark a lock as acquired or not would adjust the stats for whatever lock is at the end of the array, which may not be itself. So, do a sanity check to make sure that we're updating lock info for the proper lock. (This explains the bizarre stats on lock #63 in BE-396, thanks Mark!) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105116 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-25Improve the lock tracking code a bit so that a bunch of old locks that threadsrussell1-1/+10
failed to lock don't sit around in the history. When a lock is first locked, this checks to see if the last lock in the list was one that was failed to be locked. If it is, then that was a lock that we're no longer sitting in a trylock loop trying to lock, so just remove it. (inspired by issue #11712) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104102 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-08Increase constants to where we're less likely to hit them while debugging.tilghman1-1/+1
(Closes issue #11694) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@97194 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-17Do not try to access information about a lock when printing out a trylock ↵file1-1/+1
attempt. It is possible for the lock that it references to no longer be valid. This would have caused segfaults or deadlocks. (issue #BE-263) (closes issue #11080) Reported by: callguy (closes issue #11100) Reported by: callguy git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@93377 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-07Make the lock protecting each thread's list of locks it currently holdsrussell1-1/+6
recursive. I think that this will fix the situation where some people have said that "core show locks" locks up the CLI. (related to issue #11080) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@91830 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-05When DEBUG_THREADS is enabled, we only have the details about who is holdingrussell1-0/+4
a lock that we are waiting on for a mutex, not rwlocks. This should fix the problem where people have reported "core show locks" crashing sometimes. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@91074 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-13Debugging is running into the 16-lock limit. Increase to avoid.tilghman1-1/+1
(This define is only effective when debugging is turned on, so there's no effect for most installations.) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89239 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-29Add some more details to the output of "core show locks". When a threadrussell1-0/+15
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-29Fix issue with ast_unescape_semicolon going into an endless loop.file1-0/+2
(closes issue #10550) Reported by: ramonpeek Patches: unescape-85177-1.patch uploaded by IgorG (license 20) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@87294 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-18Revert a change that I made for issue #10979 which, as has been pointed out torussell1-3/+0
me in issue #11018, doesn't really make sense. There is no reason to have the base64 decode function force a '\0' terminated buffer, when the result is almost always binary, anyway. In fact, this caused some breakage, as some code in res_crypto passed in a buffer exactly the right size to get its binary result, which got stomped on by this patch. (closes issue #11018, reported by dimas) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@86237 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-15Be pedantic about handling memory allocation failure.russell1-1/+14
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85649 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-15The loop in the handler for the "core show locks" could potentially block forrussell1-7/+16
some amount of time. Be a little bit more careful and prepare all of the output in an intermediary buffer while holding a global resource. Then, after releasing it, send the output to ast_cli(). git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85647 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-15Make sure that the base64 decoder returns a terminated string.russell1-0/+3
(closes issue #10979) Reported by: ys Patches: util.c.diff uploaded by ys (license 281) - small mods by me git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85543 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-10The thread ID should be unsigned.mmichelson1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85315 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-09This commit fixes the following issues:tilghman1-2/+15
- 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-4/+22
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-08-17Don't send a semicolon over the wire in sip notify messages.qwell1-0/+15
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-03Add some improvements to lock debugging. These changes take effectrussell1-6/+248
with DEBUG_THREADS enabled and provide the following: * This will keep track of which locks are held by which thread as well as which lock a thread is waiting for in a thread-local data structure. A reference to this structure is available on the stack in the dummy_start() function, which is the common entry point for all threads. This information can be easily retrieved using gdb if you switch to the dummy_start() stack frame of any thread and print the contents of the lock_info variable. * All of the thread-local structures for keeping track of this lock information are also stored in a list so that the information can be dumped to the CLI using the "core show locks" CLI command. This introduces a little bit of a performance hit as it requires additional underlying locking operations inside of every lock/unlock on an ast_mutex. However, the benefits of having this information available at the CLI is huge, especially considering this is only done in DEBUG_THREADS mode. It means that in most cases where we debug deadlocks, we no longer have to request access to the machine to analyze the contents of ast_mutex_t structures. We can now just ask them to get the output of "core show locks", which gives us all of the information we needed in most cases. I also had to make some additional changes to astmm.c to make this work when both MALLOC_DEBUG and DEBUG_THREADS are enabled. I disabled tracking of one of the locks in astmm.c because it gets used inside the replacement memory allocation routines, and the lock tracking code allocates memory. This caused infinite recursion. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@78095 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-01Whoops, I meant R_5 not R5.file1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@77867 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-01Extend autoconf logic to determine which version of gethostbyname_r is on ↵file1-2/+2
the system. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@77863 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-01 06:27:56 +0000