Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216435 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211528 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
the amount available.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176945 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166297 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@153823 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@133237 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
unsafe pointers.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@125793 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@125587 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
threads when they are being closed.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@124066 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
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
|
|
(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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114051 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109838 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
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
|
|
(Closes issue #11694)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@97194 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
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
|
|
(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
|
|
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
|
|
(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
|
|
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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85649 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
(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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85315 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
- 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
|
|
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
|
|
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
|
|
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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@77867 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the system.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@77863 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
of the function. This was already done in trunk.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@72665 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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/branches/1.4@51195 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
'threadstorage' CLI commands
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@49553 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
solve a fairly small problem... such is life.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@47303 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r46560 | russell | 2006-10-31 01:18:36 -0500 (Tue, 31 Oct 2006) | 3 lines
When handling the case where the hostname is just an IPV4 numeric address,
be sure to set the address type. (issue #8247, alexr)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@46561 f38db490-d61c-443f-a65b-d21fe96a405b
|