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: http://svn.digium.com/svn/asterisk/trunk@93950 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@93378 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@91831 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@91077 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@89487 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@89333 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@89240 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@88454 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87396 | russell | 2007-10-29 15:22:07 -0500 (Mon, 29 Oct 2007) | 5 lines
Add some more details to the output of "core show locks". When a thread
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/trunk@87397 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@86238 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@85648 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r84271 | russell | 2007-10-01 16:07:06 -0500 (Mon, 01 Oct 2007) | 4 lines
Fulfull a feature request from Qwell on the "core show locks" output. It will
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/trunk@84272 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
(closes issue #10430)
........
r79904 | qwell | 2007-08-17 14:12:19 -0500 (Fri, 17 Aug 2007) | 11 lines
Don't send a semicolon over the wire in sip notify messages.
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/trunk@79905 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r78095 | russell | 2007-08-03 14:39:49 -0500 (Fri, 03 Aug 2007) | 28 lines
Add some improvements to lock debugging. These changes take effect
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/trunk@78096 f38db490-d61c-443f-a65b-d21fe96a405b
places in the code where the same block of code for creating detached threads
was replicated. (patch from bbryant)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@65968 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r51195 | tilghman | 2007-01-17 14:56:15 -0600 (Wed, 17 Jan 2007) | 12 lines
Merged revisions 51194 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r51194 | tilghman | 2007-01-17 14:52:21 -0600 (Wed, 17 Jan 2007) | 4 lines
When ast_strip_quoted was called with a zero-length string, it would treat a
NULL as if it were the quoting character (and would thus return the string
in memory immediately following the passed-in string).
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@51196 f38db490-d61c-443f-a65b-d21fe96a405b
renaming them to ast_str ... and putting the
struct ast_threadstorage pointer into the struct ast_str.
This makes the code a lot more readable.
At this point we can use these routines also to
replace ast_build_string().
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@48510 f38db490-d61c-443f-a65b-d21fe96a405b
While doing this, add a bit of documentation, and slightly
extend the functionality as follows:
+ a max_len of -1 means that we take whatever the current size
is, and never try to extend the buffer;
+ add support for alloca()-ted dynamic strings, which is very
useful for all cases where we do an ast_build_string() now.
Next step is to simplify the interface by using shorter names
(e.g. ast_str as a prefix) and removing the _thread variant
of the functions by saving the threadstorage reference into
the struct ast_str. This can be done by overloading the
'type' field.
Finally, I will do my best to remove the convoluted interface
that results from trying to support platforms without va_copy().
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@48509 f38db490-d61c-443f-a65b-d21fe96a405b
in both the append and non-append modes. Also, always truncating the partial
write makes the behavior of the function more consistent, where in any type of
write, no partial result is left in the buffer.
Thanks for the feedback, luigi
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@48109 f38db490-d61c-443f-a65b-d21fe96a405b
and also add a more verbose comment explaining why it is only needed in the
case of appending to the string for any curious readers that come along in the
future.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@48103 f38db490-d61c-443f-a65b-d21fe96a405b
ast_dynamic_str_thread_build_va_couldnt_we_choose_a_shorter_name()
I am unsure whether the truncation of the string in case of a failed
attempt should be done unconditionally. See the XXX mark.
Russel, ideas ?
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@48084 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r46200 | kpfleming | 2006-10-25 09:32:08 -0500 (Wed, 25 Oct 2006) | 2 lines
apparently developers are still not aware that they should be use ast_copy_string instead of strncpy... fix up many more users, and fix some bugs in the process
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@46201 f38db490-d61c-443f-a65b-d21fe96a405b
rizzo