Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
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/branches/1.4@46200 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
assuming it's available on Linux
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@45027 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r44955 | kpfleming | 2006-10-12 13:31:26 -0500 (Thu, 12 Oct 2006) | 2 lines
ensure that IAX2 and SIP sockets allow UDP fragmentation when running on Linux (thanks to Brian Candler on the asterisk-dev list for the tip)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@44956 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@44390 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@44378 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Every OS uses strcompat now - this was done on purpose.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@42982 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
unless we know there is actually one there
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@42185 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@41944 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@41103 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
- 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: http://svn.digium.com/svn/asterisk/trunk@40722 f38db490-d61c-443f-a65b-d21fe96a405b
|