https://origsvn.digium.com/svn/asterisk/trunk
................
r162414 | russell | 2008-12-09 16:25:06 -0600 (Tue, 09 Dec 2008) | 16 lines
Merged revisions 162413 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r162413 | russell | 2008-12-09 16:17:39 -0600 (Tue, 09 Dec 2008) | 8 lines
Remove the test_for_thread_safety() function completely.
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@162415 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r159818 | kpfleming | 2008-11-29 11:57:39 -0600 (Sat, 29 Nov 2008) | 18 lines
incorporates r159808 from branches/1.4:
------------------------------------------------------------------------
r159808 | kpfleming | 2008-11-29 10:58:29 -0600 (Sat, 29 Nov 2008) | 7 lines
update dev-mode compiler flags to match the ones used by default on Ubuntu Intrepid, so all developers will see the same warnings and errors
since this branch already had some printf format attributes, enable checking for them and tag functions that didn't have them
format attributes in a consistent way
------------------------------------------------------------------------
in addition:
move some format attributes from main/utils.c to the header files they belong in, and fix up references to the relevant functions based on new compiler warnings
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@159855 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r132964 | kpfleming | 2008-07-23 11:30:18 -0500 (Wed, 23 Jul 2008) | 10 lines
Merged revisions 132872 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r132872 | kpfleming | 2008-07-23 06:52:18 -0500 (Wed, 23 Jul 2008) | 2 lines
minor optimization for stringfields: when a field is being set to a larger 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@132965 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r118955 | tilghman | 2008-05-29 12:35:19 -0500 (Thu, 29 May 2008) | 11 lines
Merged revisions 118953 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r118953 | tilghman | 2008-05-29 12:20:16 -0500 (Thu, 29 May 2008) | 3 lines
Add some debugging code that ensures that when we do deadlock avoidance, we
don't lose the information about how a lock was originally acquired.
........
................
r118957 | tilghman | 2008-05-29 12:39:50 -0500 (Thu, 29 May 2008) | 10 lines
Merged revisions 118954 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r118954 | tilghman | 2008-05-29 12:33:01 -0500 (Thu, 29 May 2008) | 2 lines
Define also when not DEBUG_THREADS
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@118958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r115737 | mmichelson | 2008-05-12 12:55:08 -0500 (Mon, 12 May 2008) | 15 lines
Merged revisions 115735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r115735 | mmichelson | 2008-05-12 12:51:14 -0500 (Mon, 12 May 2008) | 7 lines
If a thread holds no locks, do not print any information on the thread when 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@115738 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r109447 | twilson | 2008-03-18 10:43:34 -0500 (Tue, 18 Mar 2008) | 3 lines
Go through and fix a bunch of places where character strings were being interpreted as format strings. Most of these changes are solely to make compiling with -Wsecurity and -Wformat=2 happy, and were not
actual problems, per se. I also added format attributes to any printf wrapper functions I found that didn't have them. -Wsecurity and -Wmissing-format-attribute added to --enable-dev-mode.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@109459 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r109227 | mmichelson | 2008-03-17 17:06:44 -0500 (Mon, 17 Mar 2008) | 20 lines
Merged revisions 109226 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r109226 | mmichelson | 2008-03-17 17:05:49 -0500 (Mon, 17 Mar 2008) | 12 lines
Fix a logic flaw in the code that stores lock info which is displayed
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@109228 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105116 | russell | 2008-02-28 16:23:05 -0600 (Thu, 28 Feb 2008) | 8 lines
Fix a bug in the lock tracking code that was discovered by mmichelson. The 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: https://origsvn.digium.com/svn/asterisk/trunk@105144 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104102 | russell | 2008-02-25 17:19:05 -0600 (Mon, 25 Feb 2008) | 7 lines
Improve the lock tracking code a bit so that a bunch of old locks that threads
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: https://origsvn.digium.com/svn/asterisk/trunk@104103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and likely in other places too.
This is quite useful when placing mail/html stuff in config files.
/*!
\brief Convert some C escape sequences (\b\f\n\r\t) into the
equivalent characters.
\brief s The string to be converted (will be modified).
\return The converted string.
*/
char *ast_unescape_c(char *s);
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r93377 | file | 2007-12-17 18:28:09 -0400 (Mon, 17 Dec 2007) | 7 lines
Do not try to access information about a lock when printing out a trylock 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: https://origsvn.digium.com/svn/asterisk/trunk@93378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91830 | russell | 2007-12-07 15:24:33 -0600 (Fri, 07 Dec 2007) | 5 lines
Make the lock protecting each thread's list of locks it currently holds
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: https://origsvn.digium.com/svn/asterisk/trunk@91831 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91074 | russell | 2007-12-04 18:48:47 -0600 (Tue, 04 Dec 2007) | 4 lines
When DEBUG_THREADS is enabled, we only have the details about who is holding
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: https://origsvn.digium.com/svn/asterisk/trunk@91077 65c4cc65-6c06-0410-ace0-fbb531ad65f3
would return LONG_MIN (1 in 9 quintillion if using 64-bit longs). Since there
is no positive equivalent of LONG_MIN, the result of labs() in this case is
unpredictable. This fixes that situation.
(closes issue #11336, reported and patched by sperreault)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89487 65c4cc65-6c06-0410-ace0-fbb531ad65f3
build times - tested, there is no measureable difference before and
after this commit.
In this change:
use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h
Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.
Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better.
For the time being I have left alone second-level directories
(main/db1-ast, etc.).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89239 | tilghman | 2007-11-13 07:51:53 -0600 (Tue, 13 Nov 2007) | 4 lines
Debugging is running into the 16-lock limit. Increase to avoid.
(This define is only effective when debugging is turned on, so there's
no effect for most installations.)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
details and examples are in include/asterisk/stringfields.h.
Not applicable to older branches except for 1.4 which will
receive a fix for the routines that free memory pools.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88454 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r86237 | russell | 2007-10-17 23:40:52 -0500 (Wed, 17 Oct 2007) | 9 lines
Revert a change that I made for issue #10979 which, as has been pointed out to
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: https://origsvn.digium.com/svn/asterisk/trunk@86238 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r85647 | russell | 2007-10-15 14:11:38 -0500 (Mon, 15 Oct 2007) | 5 lines
The loop in the handler for the "core show locks" could potentially block for
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: https://origsvn.digium.com/svn/asterisk/trunk@85648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
