summaryrefslogtreecommitdiff
path: root/main/lock.c
AgeCommit message (Collapse)Author
2016-09-23chan_sip: Address runaway when realtime peers subscribe to mailboxesGeorge Joseph
Users upgrading from asterisk 13.5 to a later version and who use realtime with peers that have mailboxes were experiencing runaway situations that manifested as a continuous stream of taskprocessor congestion errors, memory leaks and an unresponsive chan_sip. A related issue was that setting rtcachefriends=no NEVER worked in asterisk 13 (since the move to stasis). In 13.5 and earlier, when a peer tried to register, all of the stasis threads would block and chan_sip would again become unresponsive. After 13.5, the runaway would happen. There were a number of causes... * mwi_event_cb was (indirectly) calling build_peer even though calls to mwi_event_cb are often caused by build_peer. * In an effort to prevent chan_sip from being unloaded while messages were still in flight, destroy_mailboxes was calling stasis_unsubscribe_and_join but in some cases waited forever for the final message. * add_peer_mailboxes wasn't properly marking the existing mailboxes on a peer as "keep" so build_peer would always delete them all. * add_peer_mwi_subs was unsubscribing existing mailbox subscriptions then just creating them again. All of this was causing a flood of subscribes and unsubscribes on multiple threads all for the same peer and mailbox. Fixes... * add_peer_mailboxes now marks mailboxes correctly and build_peer only deletes the ones that really are no longer needed by the peer. * add_peer_mwi_subs now only adds subscriptions marked as "new" instead of unsubscribing and resubscribing everything. It also adds the peer object's address to the mailbox instead of its name to the subscription userdata so mwi_event_cb doesn't have to call build_peer. With these changes, with rtcachefriends=yes (the most common setting), there are no leaks, locks, loops or crashes at shutdown. rtcachefriends=no still causes leaks but at least it doesn't lock, loop or crash. Since making rtcachefriends=no work wasnt in scope for this issue, further work will have to be deferred to a separate patch. Side fixes... * The ast_lock_track structure had a member named "thread" which gdb doesn't like since it conflicts with it's "thread" command. That member was renamed to "thread_id". ASTERISK-25468 #close Change-Id: I07519ef7f092629e1e844f855abd279d6475cdd0
2016-04-21lock.c: Check *lt before dereferencing itDiederik de Groot
*lt is NULL if t->tracking == 0 ASTERISK-25948 #close Change-Id: I4a81af28f9c82a74aa82413d772a7dc8fa6f45ba
2014-12-12DEBUG_THREADS: Fix regression and lock tracking initialization problems.Richard Mudgett
This patch started with David Lee's patch at https://reviewboard.asterisk.org/r/2826/ and includes a regression fix introduced by the ASTERISK-22455 patch. The initialization of a mutex's lock tracking structure was not protected in a critical section. This is fine for any mutex that is explicitly initialized, but a static mutex may have its lock tracking double initialized if multiple threads attempt the first lock simultaneously. * Added a global mutex to properly serialize initialization of the lock tracking structure. The painful global lock can be mitigated by adding a double checked lock flag as discussed on the original review request. * Defer lock tracking initialization until first use. * Don't be "helpful" and initialize an uninitialized lock when DEBUG_THREADS is enabled. Debug code is not supposed to fix or change normal code behavior. We don't need a lock initialization race that would force a re-setup of lock tracking. Lock tracking already handles initialization on first use. * Properly handle allocation failures of the lock tracking structure. * No need to initialize tracking data in __ast_pthread_mutex_destroy() just to turn around and destroy it. The regression introduced by ASTERISK-22455 is the result of manipulating a pthread_mutex_t struct outside of the pthread library code. The pthread_mutex_t struct seems to have a global linked list pointer member that can get changed by other threads. Therefore, saving and restoring the contents of a pthread_mutex_t struct is a bad thing. Thanks to Thomas Airmont for finding this obscure regression. * Don't overwrite the struct ast_lock_track.reentr_mutex member to restore tracking data in __ast_cond_wait() and __ast_cond_timedwait(). The pthread_mutex_t struct must be treated as a read-only opaque variable. Miscellaneous other items fixed by this patch: * Match ast_suspend_lock_info() with ast_restore_lock_info() in __ast_cond_timedwait(). * Made some uninitialized lock sanity checks return EINVAL and try a DO_THREAD_CRASH. * Fix bad canlog initialization expressions. ASTERISK-24614 #close Reported by: Thomas Airmont Review: https://reviewboard.asterisk.org/r/4247/ Review: https://reviewboard.asterisk.org/r/2826/ ........ Merged revisions 429539 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429540 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-25Revert -r411073. It didn't help and blew up the system.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411087 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-24locking: Add temporary sanity checks.Richard Mudgett
Add some temporary sanity checks to hunt for locking problems with the masquerade supertest. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411073 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-09Fix DEBUG_THREADS when lock is acquired in __constructor__David M. Lee
This patch fixes some long-standing bugs in debug threads that were exacerbated with recent Optional API work in Asterisk 12. With debug threads enabled, on some systems, there's a lock ordering problem between our mutex and glibc's mutex protecting its module list (Ubuntu Lucid, glibc 2.11.1 in this instance). In one thread, the module list will be locked before acquiring our mutex. In another thread, our mutex will be locked before locking the module list (which happens in the depths of calling backtrace()). This patch fixes this issue by moving backtrace() calls outside of critical sections that have the mutex acquired. The bigger change was to reentrancy tracking for ast_cond_{timed,}wait, which wrongly assumed that waiting on the mutex was equivalent to a single unlock (it actually suspends all recursive locks on the mutex). (closes issue ASTERISK-22455) Review: https://reviewboard.asterisk.org/r/2824/ ........ Merged revisions 398648 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 398649 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 398651 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@398652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-23Fix memory corruption when trying to get "core show locks".Richard Mudgett
Review https://reviewboard.asterisk.org/r/2580/ tried to fix the mismatch in memory pools but had a math error determining the buffer size and didn't address other similar memory pool mismatches. * Effectively reverted the previous patch to go in the same direction as trunk for the returned memory pool of ast_bt_get_symbols(). * Fixed memory leak in ast_bt_get_symbols() when BETTER_BACKTRACES is defined. * Fixed some formatting in ast_bt_get_symbols(). * Fixed sig_pri.c freeing memory allocated by libpri when MALLOC_DEBUG is enabled. * Fixed __dump_backtrace() freeing memory from ast_bt_get_symbols() when MALLOC_DEBUG is enabled. * Moved __dump_backtrace() because of compile issues with the utils directory. (closes issue ASTERISK-22221) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2778/ ........ Merged revisions 397525 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 397528 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-15Fix for segfault in __ast_rwlock_destroy with DEBUG_THREADSKevin Harwell
If DEBUG_THREADS is enabled __ast_rwlock_destroy causes a segfault while trying to access a possible NULL t->track object. A NULL check has been added before trying to access the memory. (closes issue ASTERISK-21724) Reported by: Corey Farrell Fixed by: Corey Farrell Patches: ast_rwlock_destroy-segv.patch uploaded by Corey Farrell (license 5909) ........ Merged revisions 388838 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 388839 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2012-11-23Re-initialize logmsgs mutex upon logger initialization to prevent lock errorsMatthew Jordan
Similar to the patch that moved the fork earlier in the startup sequence to prevent mutex errors in the recursive mutex surrounding the read/write thread registration lock, this patch re-initializes the logmsgs mutex. Part of the start up sequence before forking the process into the background includes reading asterisk.conf; this has to occur prior to the call to daemon in order to read startup parameters. When reading in a conf file, log statements can be generated. Since this can't be avoided, the mutex instead is re-initialized to ensure a reset of any thread tracking information. This patch also includes some additional debugging to catch errors when locking or unlocking the recursive mutex that surrounds locks when the DEBUG_THREADS build option is enabled. DO_CRASH or THREAD_CRASH will cause an abort() if a mutex error is detected. (issue ASTERISK-19463) Reported by: mjordan Tesetd by: mjordan ........ Merged revisions 376586 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 376587 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 376588 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2012-08-27Fixes ast_rwlock_timed[rd|wr]lock for BSD and variants.David M. Lee
The original implementations simply wrap pthread functions, which take absolute time as an argument. The spinlock version for systems without those functions treated the argument as a delta. This patch fixes the spinlock version to be consistent with the pthread version. (closes issue ASTERISK-20240) Reported by: Egor Gorlin Patches: lock.c.patch uploaded by Egor Gorlin (license 6416) ........ Merged revisions 371718 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 371720 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371721 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2012-06-15Multiple revisions 369001-369002Kevin P. Fleming
........ r369001 | kpfleming | 2012-06-15 10:56:08 -0500 (Fri, 15 Jun 2012) | 11 lines Add support-level indications to many more source files. Since we now have tools that scan through the source tree looking for files with specific support levels, we need to ensure that every file that is a component of a 'core' or 'extended' module (or the main Asterisk binary) is explicitly marked with its support level. This patch adds support-level indications to many more source files in tree, but avoids adding them to third-party libraries that are included in the tree and to source files that don't end up involved in Asterisk itself. ........ r369002 | kpfleming | 2012-06-15 10:57:14 -0500 (Fri, 15 Jun 2012) | 3 lines Add a script to enable finding source files without support-levels defined. ........ Merged revisions 369001-369002 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 369005 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2012-03-22Kill off red blobs in most of main/*Kinsey Moore
Everything still compiled after making these changes, so I assume these whitespace-only changes didn't break anything (and shouldn't have). git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-04-20Merged revisions 314358 via svnmerge from Terry Wilson
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r314358 | twilson | 2011-04-19 22:25:15 -0700 (Tue, 19 Apr 2011) | 4 lines Initialize track pointer ast_reentrancy_init checks to see if it is NULL before initializing with calloc ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-02-09Merged revisions 307142 via svnmerge from Tilghman Lesher
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r307142 | tilghman | 2011-02-08 23:39:39 -0600 (Tue, 08 Feb 2011) | 3 lines Initialize tracking variable in structure properly. Fixes a memory leak. (Reported by The_Boy_Wonder on IRC, fixed by me.) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307143 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-31Merged revisions 304950 via svnmerge from Tilghman Lesher
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r304950 | tilghman | 2011-01-31 00:41:36 -0600 (Mon, 31 Jan 2011) | 18 lines Change mutex tracking so that it only consumes memory in the core mutex object when it's actually being used. This reduces the overall size of a mutex which was 3016 bytes before this back down to 216 bytes (this is on 64-bit Linux with a glibc-implemented mutex). The exactness of the numbers here may vary slightly based upon how mutexes are implemented on a platform, but the long and short of it is that prior to this commit, chan_iax2 held down 98MB of memory on a 64-bit system for nothing more than a table of 32767 locks. After this commit, the same table occupies a mere 7MB of memory. (closes issue #18194) Reported by: job Patches: 20110124__issue18194.diff.txt uploaded by tilghman (license 14) Tested by: tilghman Review: https://reviewboard.asterisk.org/r/1066 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@304951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-09Attempt to fix FreeBSD build problem.Russell Bryant
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269569 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-22Remove ABI differences that occured when compiling with DEBUG_THREADS.Jason Parker
"Bad Things" would happen if Asterisk was compiled with DEBUG_THREADS, but a loaded module was not (or vice versa). This also immensely simplifies the lock code, since there are no longer 2 separate versions of them. Review: https://reviewboard.asterisk.org/r/508/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-26 12:09:16 +0000