This deadlock was introduced by the fix to ensure that channels are properly
locked when handling channel variables. There were sections of this code where
the channel pvt was locked before the channel lock, when in fact it _must_ be
the other way around.
(closes issue #11582)
Reported by: bugi
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@94251 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r94214 | russell | 2007-12-20 11:29:11 -0600 (Thu, 20 Dec 2007) | 2 lines
Fix a couple of places where it's possible to dereference a NULL pointer.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@94215 65c4cc65-6c06-0410-ace0-fbb531ad65f3
needs to use this if the user does not have soxmix.
(closes issue #11589, reported by amessina, patch inspired by amessina but with a flourish from me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@94122 65c4cc65-6c06-0410-ace0-fbb531ad65f3
tomorrow's tomorrow is the day after tomorrow, so who cares if you
recycle anyway?
If this confuses you, that's nothing compared to what this fixes. ;-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@93336 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I wonder if Asterisk can run at all without res_features. My guess is that
there's propably a lot of more modules and the core that depends on it.
Reported by: caio1982
(closes issue #11574)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@93182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
rizzo brought up some issues related to the way that the metadata required
for menuselect and the rest of the build system is extracted from the source
files. Since I had a few hours to kill on an airplane today, I decided to
improve this situation... so now the system caches the extracted metadata
and uses it to build the menuselect 'tree' as much as it can. The result
of this is that when a single source file is changed, only the metadata for
that file needs to be extracted again, and the rest is used from the cache
files. I also reduced the number of forked processes required to do the
metadata extraction; it was actually possible to do most of what we needed
in the Makefiles themselves without using any shell scripts at all! On my
laptop, these changes resulted in an 80% decrease in the time required
for the 'menuselect.makeopts' automatic check to occur after editing a single
source file.
While doing this work I also cleaned up a few minor things in the Makefiles,
adding a check for 'awk' to the configure script and changed all remaining
places we use 'grep' or 'awk' to use the ones found by the configure script,
and changed the 'prep_tarball' script to build the menuselect metadata so
that tarballs of Asterisk will include it and won't require the user to
wait while it is extracted after unpacking.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@93180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
make the transition to treating this as an error a bit less painless, just issue
a huge error message for now. Then, later, we can reinstate the code that treats
it as a failure.
(Thanks to philippel for the feedback)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@93000 65c4cc65-6c06-0410-ace0-fbb531ad65f3
about possible deadlocks. Instead just print the intended single message every
five seconds.
(closes issue 11537, reported and patched by dimas)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92875 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We do not want to do this (see bug below for details).
This makes it so that if a [ is found without a ], the entire config will fail, and nothing in it will be loaded.
Isue #10690.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the channel which initiated the bridge was always assumed to have been the one
which activated the dynamic feature. This patch corrects this.
(closes issue #11529, reported and patched by nic_bellamy)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
caller were ringing members (but not yet bridged) there could be available members
and waiting callers who would not get matched up. The member availability checker
was correctly determining the number of available members in this scenario, but
the queue itself did not parallelly reflect this status on the pending calls. This
commit corrects the issue.
(closes issue #11459, reported by equissoftware, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92323 65c4cc65-6c06-0410-ace0-fbb531ad65f3
duplicate dialed numbers will be skipped, meaning the datastore isn't created. This means
that when we try to free it, there's a crash. This stops that crash from occurring.
(closes issue #11499, reported by slavon, patched by eliel)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92202 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to reinvite each other in 1.4 and trunk.
This patch implements support for the 491 error code that
Asterisk 1.4 generates on situations where we get an
incoming INVITE and already has one in progress.
Thanks to mavetju for reporting and to Raj Jain for an
excellent explanation of the problem.
Patch by myself. Tested with 8 Asterisk servers connected
to each other in a training network.
Closes issue #10481
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@91828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@91826 65c4cc65-6c06-0410-ace0-fbb531ad65f3
