| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@93336 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@93180 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
versions of PostgreSQL are no longer acceptable.
(Closes issue #11526)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@92463 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
against older Asterisk 1.4 headers will now load properly with just a warning
indicating that they are old and may cause problems.
(patch by paravoid)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@91501 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Discovered during Asterisk training in Portugal)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@91366 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
compiler is being used, then a warning will show up for any modules still using
the old name "private" instead of "_private".
(patch suggested by paravoid)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@91032 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: snuffy
Patch by: snuffy,tilghman
(Closes issue #11430)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90753 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90735 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
operation happens. (issue #BE-88)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90548 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Now, it automatically increases the reference count to reflect the reference
that is now held by the container.
This was done to be more consistent with ao2_unlink(), which automatically
releases the reference held by the container. It also makes it so it is
no longer possible for a pointer to be invalid after ao2_link() returns.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90348 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90310 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: chewbacca
Patch by: casper
(Closes issue #11401)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90155 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The ast_set_callerid() function needed to lock the channel. Also, the handlers
for the CALLERID() dialplan function needed to lock the channel when reading
or writing callerid values directly on the channel structure.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90145 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This makes ast_stopstream() thread-safe.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90142 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
handle locking the channel as needed
- update ast_explicit_goto() to lock the channel as needed
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89893 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
another
codec that we don't know, Asterisk did not remove that codec from the list.
With this patch, we remove the codec from audio and video rtp objects and
deny it ever existed. Thanks to lasse for testing.
(closes issue #11376)
Reported by: lasse
Patches:
bug11376.txt uploaded by oej (license 306)
Tested by: lasse
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89630 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
cdr.conf file, I added the option 'unanswered', which defaults to 'no'. In this mode, you will see a cdr for a call, whether it was answered or not. The disposition will be NO ANSWER or ANSWERED, as appropriate. The src is as you'd expect, the destination channel will be one of the channels from the Dial() call, usually the last in the list if more than one chan was specified. With unanswered set to 'yes', you will still see this cdr entry in both cases. But in the case where the dial timed out, you will also see a cdr for each line attempted, marked NO ANSWER, with no destination channel name. The new option defaults to 'no', so you don't see the pesky extra cdr's by default, and you will not see the irritating 'not posted' messages.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89622 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
a backslash. Unfortunately, this does not universally work on all databases,
since on databases which natively use the backslash as a delimiter, the
backslash itself needs to be delimited, but on other databases that have no
delimiter, backslashing the backslash causes an error.
So the only solution that I can come up with is to create an option in res_odbc
that explicitly specifies whether or not backslash is a native delimiter. If
it is, we use it natively; if not, we use the ESCAPE clause to make it one.
Reported by: elguero
Patch by: tilghman
(Closes issue #11364)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89559 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89462 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
a string-based storage and comparison mechanism because it is easier to support on other platforms
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89461 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
what build options were used. We agreed that we should remove this before
making a 1.4 release, and then we can put it back in. Then, we can take a
month or so to play around with it to get it how we want it.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89339 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
or others) and then change the build options of the Asterisk build in a way that makes the incompatible without warning, this commit introduces an MD5 signature of the important build-time options and includes that signature into modules when they are built. When the loader loads one of these modules and notices the problem, it will emit a warning to console and refuse to initialize the module, as doing so could cause the system to be unstable or even crash.
If you upgrade to this version of Asterisk, you must rebuild *all* of your modules that came from other sources before trying to run this version. If you are using Digium's G.729 binary codec module, you will need v33 or newer.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89325 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
then never turned it on (oops).
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89045 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88862 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@88805 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@88719 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@88471 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
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
|
|
contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@87168 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
require the user to do that
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@87069 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
and modify channel data that may change elsewhere. I went through every timer
callback in the source tree to make sure that none of them did any additional
locking that could introduce deadlocks, and all is well.
(closes issue #10765)
Reported by: Ivan
Patches:
ast_1_4_11_svn_patch_channel_rc.diff uploaded by Ivan (license 229)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@86330 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85997 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
character set don't get stripped when reading configuration.
(closes issue #10982, dandre)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85561 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
command
and retrieve its output. The issue was that there was no way for the main Asterisk
process to know that the remote console was connecting in the -rx mode. The way that
James has fixed this is to have all remote consoles muted by default. Then, regular
remote consoles automatically execute a CLI command to unmute themselves when they
first start up.
(closes issue #10847)
Reported by: atis
Patches:
asterisk-consolemute.diff.txt uploaded by jamesgolovich (license 176)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85533 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
CLI command at once for a remote console.
(closes issue #10888)
Reported by: jamesgolovich
Patches:
asterisk-climultiple.diff.txt uploaded by jamesgolovich (license 176)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85532 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
in the middle of the struct, instead of at the end. One of the Debian folks,
paravoid, pointed out that this breaks binary compatability with modules
compiled against older headers. So, I'm moving the new member to the end
of the struct to resolve the situation.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85316 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the caller of ast_frame_free() properly
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85195 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
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84206 f38db490-d61c-443f-a65b-d21fe96a405b
|
