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
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: https://origsvn.digium.com/svn/asterisk/trunk@79905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@78096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
places in the code where the same block of code for creating detached threads
was replicated. (patch from bbryant)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@65968 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@51196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@48510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@48509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@48109 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@48103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@48084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
be called for each thread specific object after they are allocated. Note that
there was already the ability to define a custom cleanup function. Also, if
the custom cleanup function is used, it *MUST* call free on the thread
specific object at the end. There is no way to have this magically done that
I can think of because the cleanup function registered with the pthread
implementation will only call the function back with a pointer to the
thread specific object, not the parent ast_threadstorage object.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@45623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r44378 | kpfleming | 2006-10-04 14:47:22 -0500 (Wed, 04 Oct 2006) | 4 lines
update thread creation code a bit
reduce standard thread stack size slightly to allow the pthreads library to allocate the stack+data and not overflow a power-of-2 allocation in the kernel and waste memory/address space
add a new stack size for 'background' threads (those that don't handle PBX calls) when LOW_MEMORY is defined
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@44379 65c4cc65-6c06-0410-ace0-fbb531ad65f3
large enough and had to be reallocated, cut off the partially appended data.
Otherwise, the function will get called over and over again appending to the
end every time and never thinking it has enough room.
Thanks to jmls for access to his machine for debugging!
(issue #7691)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@41944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- 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: https://origsvn.digium.com/svn/asterisk/trunk@40722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Luigi Rizzo
Tilghman Lesher
Russell Bryant
Joshua Colp
Jason Parker
Steve Murphy
Kevin P. Fleming