aboutsummaryrefslogtreecommitdiffstats
path: root/include/asterisk/lock.h
AgeCommit message (Collapse)AuthorFilesLines
2008-06-30Fix a typo in the non-DEBUG_THREADS version of the recently added ↵russell1-2/+2
DEADLOCK_AVOIDANCE() macro. This caused the lock to not actually be released, and as a result, not avoid deadlocks at all. This resolves the issues reported in the last while about Asterisk locking up all over the place (and most commonly, in chan_iax2). (closes issue #12927) (closes issue #12940) (closes issue #12925) (potentially closes others ...) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@126573 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-27In this debugging function, copy to a buffer instead of using potentially ↵tilghman1-4/+4
unsafe pointers. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@125793 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29Define also when not DEBUG_THREADStilghman1-0/+5
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@118954 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29Add some debugging code that ensures that when we do deadlock avoidance, wetilghman1-0/+32
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
2008-05-13A change to the way channel locks are handled when DEBUG_CHANNEL_LOCKS is ↵mmichelson1-3/+6
defined. After debugging a deadlock, it was noticed that when DEBUG_CHANNEL_LOCKS is enabled in menuselect, the actual origin of channel locks is obscured by the fact that all channel locks appear to happen in the function ast_channel_lock(). This code change redefines ast_channel_lock to be a macro which maps to __ast_channel_lock(), which then relays the proper file name, line number, and function name information to the core lock functions so that this information will be displayed in the case that there is some sort of locking error or core show locks is issued. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@116088 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-10Fix 1.4 build when LOW_MEMORY is enabled.mmichelson1-0/+17
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114051 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-28Fix a bug in the lock tracking code that was discovered by mmichelson. The ↵russell1-9/+9
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
2007-12-14When compiling with DETECT_DEADLOCKS, don't spam the CLI with messagesmmichelson1-4/+5
about possible deadlocks. Instead just print the intended single message every five seconds. (closes issue 11537, reported and patched by dimas) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@92875 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-07Fix another bug in the DEBUG_THREADS code. The ast_mutex_init() function hadrussell1-1/+1
the mutex attribute object marked as static. This means that multiple threads initializing locks at the same time could step on each other and end up with improperly initialized locks. (found when tracking down locking issues related to issue #11080) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@91828 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-07I love fixing lock related errors in the lock debugging code. That's about asrussell1-1/+1
ironic as it gets in Asterisk programming land. Anyway, I spotted this bug while trying to track down why systems are locking up and acting weird in issue #11080. The mutex attribute object was marked as static in this function when it should not have been. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@91826 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-05Fix some crashes in chan_iax2 that were reported as happening on Mac systems.russell1-2/+2
It turns out that the problem was the Mac version of the ast_atomic_fetchadd_int() function. The Mac atomic add function returns the _new_ value, while this function is supposed to return the old value. So, the crashes happened on unreferencing objects. If the reference count was decreased to 1, ao2_ref() thought that it had been decreased to zero, and called the destructor. However, there was still an outstanding reference around. (closes issue #11176) (closes issue #11289) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@91070 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-06We went to the trouble of creating a method of tracking failed trylocks, ↵tilghman1-1/+1
then never turned it on (oops). git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89045 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-06Remove some checks to see if locks are initialized from the non-DEBUG_THREADSrussell1-67/+0
versions of the lock routines. These are incorrect for a number of reasons: - It breaks the build on mac. - If there is a problem with locks not getting initialized, then the proper fix is to find that place and fix the code so that it does get initialized. - If additional debug code is needed to help find the problem areas, then this type of things should _only_ be put in the DEBUG_THREADS wrappers. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88931 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-02Fix build on Solaristilghman1-29/+29
Reported by: snuffy Patch by: ys Closes issue #11143 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88210 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-30Fix for uninitialized mutexes on *BSDtilghman1-67/+298
Reported by: ys Fixed by: ys Closes issue #11116 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@87739 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-29Add some more details to the output of "core show locks". When a threadrussell1-24/+24
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
2007-10-22If lock tracking is not enabled, then we can not attempt to log any mutexrussell1-4/+19
failures. If so, we could end up in infinite recursion. The only lock that is affected by this is a mutex in astmm.c used when MALLOC_DEBUG is enabled. (closes issue #11044) Reported by: ys Patches: lock.h.diff uploaded by ys (license 281) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@86836 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-22Update the static mutex initializer to include the initialization ofrussell1-2/+2
the internal mutex used to protect the lock debugging data. (closes issue #11044, patch suggested by Ivan) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@86726 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-16really picky formatting tweak ...russell1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85997 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-16Some locking errors exposed the fact that the lock debugging code itself wasrussell1-19/+71
not thread safe. How ironic! Anyway, these changes ensure that the code that is accessing the lock debugging data is thread-safe. Many thanks to Ivan for finding and fixing the core issue here, and also thanks to those that tested the patch and provided test results. (closes issue #10571) (closes issue #10886) (closes issue #10875) (might close some others, as well ...) Patches: (from issue #10571) ivan_ast_1_4_12_rel_patch_lock.h.diff uploaded by Ivan (license 229) - a few small changes by me git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85994 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-09This commit fixes the following issues:tilghman1-4/+12
- 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
2007-10-01Fulfull a feature request from Qwell on the "core show locks" output. It willrussell1-10/+17
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
2007-10-01Show rwlocks in the "core show locks" output. Before, it only showed mutexes.russell1-0/+79
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84206 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-09Fix inline compiles on really old compilers (who uses gcc 2.7 anymore, really?)tilghman1-3/+11
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@82028 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-05Solaris x86 compatibility fixtilghman1-0/+4
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@81569 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-10The last set of changes that I made to "core show locks" made it not able torussell1-9/+17
track mutexes unless they were declared using AST_MUTEX_DEFINE_STATIC. Locks initialized with ast_mutex_init() were not tracked. It should work now. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@78995 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-05Fix compilation failure when MALLOC_DEBUG is enabled, but DEBUG_THREADS is notrussell1-0/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@78143 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-03Add some improvements to lock debugging. These changes take effectrussell1-9/+67
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
2007-07-24Merged revisions 76934 via svnmerge from tilghman1-1/+1
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r76934 | tilghman | 2007-07-24 17:11:33 -0500 (Tue, 24 Jul 2007) | 2 lines Oops, res contains the error code, not errno. I was wondering why a mutex was reporting "No such file or directory"... ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@76937 f38db490-d61c-443f-a65b-d21fe96a405b
2006-12-28Backport support for read/write locks.file1-0/+66
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@49022 f38db490-d61c-443f-a65b-d21fe96a405b
2006-10-30Issue #8246 - Doxygen fixes from kshumard. oej1-1/+1
An extra big thankyou is given to everyone that contributes to doxygen! THANK YOU! git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@46433 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-28eliminate compiler warning when DEBUG_CHANNEL_LOCKS is enabled and users of ↵kpfleming1-0/+2
this header file don't also include channel.h git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@43952 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-18don't need two copies of thiskpfleming1-50/+19
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43239 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-18a little cleanup and simplification, and remove ON_FIRST_USE mode since ↵kpfleming1-111/+32
nobody uses it git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43237 f38db490-d61c-443f-a65b-d21fe96a405b
2006-08-21merge new_loader_completion branch, including (at least):kpfleming1-2/+0
- 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
2006-08-17Use OSAtomicAdd instead of OSAtomicDecrement to decrement the value by 1.file1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@40303 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-30fix the condition for including the header for osx atomicsrussell1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@36421 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-30add support for atomic operations provided by mac osxrussell1-1/+23
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@36409 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-13use atomic operations provided by the compiler if they are available (yay ↵kpfleming1-4/+15
for gcc 4.1 users!) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@33953 f38db490-d61c-443f-a65b-d21fe96a405b
2006-06-11suppress warnings when building with DEBUG_CHANNEL_LOCKS (issue #7330, casper)russell1-0/+2
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@33550 f38db490-d61c-443f-a65b-d21fe96a405b
2006-05-23restore AST_LIST_HEAD_INIT (with no users in the tree right now)kpfleming1-6/+15
update ast_mutex_init to allow mutexes that are all zero bytes to be initialized (in the case of a dynamically-allocated structure containing a mutex) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@29727 f38db490-d61c-443f-a65b-d21fe96a405b
2006-05-11set correct type for lock initializersrizzo1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@26991 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-16- Fixes to ast_channel_lock functionsoej1-1/+1
- New get_sip_pvt_byid function (not really used correctly yet...) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@20424 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-15More ast_channel_lock fixesoej1-3/+17
- Update lock.h with definitions of ast_channel_lock, ast_channel_unlock and ast_channel_trylock - Convert some functions (but not all) in channel.c - Fix some bugs in chan_sip.c - Convert rest of chan_sip.c git-svn-id: http://svn.digium.com/svn/asterisk/trunk@20295 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-15New functions for locking a channel - these simplify debuggingoej1-0/+12
when you have channel locking issues. (Part of the SIP transfer patch, where I had a *lot* of channel locking problems) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@20264 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-14temporarily revert the way mutex are initialized on BSD systems.rizzo1-1/+1
This fixes the compilation on OS/X (the change exposed a wrong assumption on mutex types on OS/X), but still leaves open the bugs in initializing mutex on bsd systems, which you will see reported as 'locking failures' on certain operations. I need to investigate the issue further, but the best thing i can do now is leave things as they have been for months. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@19973 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-12simplify macro usagekpfleming1-10/+9
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@19614 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-12add 'show threads' and 'show profile' commands.rizzo1-1/+34
These are momstly debugging tools for developers, a bit documented in the header files (utils.h), although more documentation is definitely necessary. The performance impact is close to zero(*) so there is no need to compile it conditionally. (*) not completely true - thread destruction still needs to search a list _but_ this can be easily optimized if we end up with hundreds of active threads (in which case, though, the problem is clearly elsewhere). git-svn-id: http://svn.digium.com/svn/asterisk/trunk@19544 f38db490-d61c-443f-a65b-d21fe96a405b
2006-04-11fix various bugs in the DEBUG_THREADS code including:rizzo1-4/+4
- misspelled ast_mutex_logger() instead of __ast_mutex_logger() - misplaced #define ast_mutex_init(pmutex) - wrong arguments to __ast_mutex_logger() in one instance. Clearly this code is too spaghetti! git-svn-id: http://svn.digium.com/svn/asterisk/trunk@19396 f38db490-d61c-443f-a65b-d21fe96a405b
2006-03-31- Change AST_INLINE_AP to AST_INLINE_API for non-386 systems :-)oej1-5/+9
- Doxygen changes git-svn-id: http://svn.digium.com/svn/asterisk/trunk@16615 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-20 12:16:15 +0000