A huge thanks go to lvl- for patiently providing the necessary valgrind output
that was necessary to finding this problem of memory corruption.
Reported by: lvl-
Patch by: tilghman
Closes issue #11174
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in extensions.conf AND maintain their escaped characters when forming URI's
(closes issue #10681, reported by cahen, patched by me, code review by file)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
issue a reload, further use of that class could result in a crash due to
dividing by zero. This set of changes fixes up some places to prevent this
from happening.
(closes issue #10948)
Reported by: jcomellas
Patches:
res_musiconhold_division_by_zero.patch uploaded by jcomellas (license 282)
Additional changes added by me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89037 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@88931 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ways that channel variables are handled. In general, they were not handled in
a thread-safe way. The channel _must_ be locked when reading or writing from/to
the channel variable list.
What I have done to improve this situation is to make pbx_builtin_setvar_helper()
and friends lock the channel when doing their thing. Asterisk API calls almost
all lock the channel for you as necessary, but this family of functions did not.
(closes issue #10923, reported by atis)
(closes issue #11159, reported by 850t)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88805 65c4cc65-6c06-0410-ace0-fbb531ad65f3
asterisk channel must be locked, as this data may change at any time.
(I have seen numerous reports of crashes related to the handling of channel
variables. There are a couple of issues on the bug tracker related to it,
but it has also been noted on IRC and mailing lists. So, I am finding and
fixing some places where channel variables are handled improperly.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, the SRV record support in Asterisk was broken. There was no
guarantee on what record Asterisk would choose to actually use. This set of
changes improves the situation by ensuring that Asterisk will choose the
highest priority record.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88719 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The issue here is that the channel frame readq handling got broken when the
code was converted to use the linked list macros. It caused corruption of the
list head and tail pointers. So, I fixed up the usage of the linked list
macros and in passing, simplified the code. I also documented what the code
is doing, as it was a bit difficult to figure out at first.
This bug showed itself with crashes showing messed up head/tail pointers for
the readq. However, there are a couple of crashes that aren't quite as obvious,
but I think may be related. So, if your bug gets closed by this commit, but
you still have a problem, please reopen or create a new bug report.
(closes issue #10936)
(closes issue #10595)
(closes issue #10368)
(closes issue #11084)
(closes issue #10040)
(closes issue #10840)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88709 65c4cc65-6c06-0410-ace0-fbb531ad65f3
any channel datastores from the old channel to the new one. However, it did
not use the linked list macros properly to accomplish the task. The existing
code would only work if there was only a single datastore on the old channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88624 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and ast_string_field_free_all to ast_string_field_reset_all
to avoid misuse (due to too similar names and an error in
documentation). Fix two related memory leaks in app_meetme.
No need to merge to trunk, different fix already applied there.
Not applicable to 1.2
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a race condition related to the handling of POKEing peers. Essentially,
a reference to a peer is held by the scheduler when there are pending callbacks,
but the reference count didn't reflect it. So, it was possible for a peer to hit
a reference count of zero and have its destructor begin to be called at the same
time that the scheduler thread ran a POKE related callback. If that happened,
a crash would likely occur.
(closes issue #11082, closes issue #11094)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@87686 65c4cc65-6c06-0410-ace0-fbb531ad65f3
