This resolves a large number of compiler warnings from GCC 4.10 which
cause the build to fail under dev mode. The vast majority are
signed/unsigned mismatches in printf-style format strings.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@413586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ast_filestream object gets tacked on to a channel via
chan->timingdata. It's a reference counted object, but the reference
count isn't used when putting it on a channel. It's theoretically
possible for another thread to interfere with the channel while it's
unlocked and cause the filestream to get destroyed.
Use the astobj2 reference count to make sure that as long as this code
path is holding on the ast_filestream and passing it into the file.c
playback code, that it knows it's valid.
Bug reported by Leif Madsen.
Review: https://reviewboard.asterisk.org/r/3135/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@406566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch came about due to a problem observed where wav files had an
empty header. The header is supposed to be updated in wav_close(). It
turns out that this was broken when the cache_record_files option from
asterisk.conf was enabled. The cleanup code was moving the file to its
final destination *before* running the close() method of the file
destructor, so the header didn't get updated.
Another problem here is that the move was being done before actually
closing the FILE *.
Finally, the last bug fixed here is that I noticed that wav_close()
checks for stream->filename to be non-NULL. In the previous cleanup
order, it's checking a pointer to freed memory. This doesn't actually
cause anything to break, but it's treading on dangerous waters. Now the
free() of stream->filename is happening after the format module's
close() method gets called, so it's safer.
Review: https://reviewboard.asterisk.org/r/2286/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380210 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes three main issues
* Change asprintf() uses to ast_asprintf() so that it
pairs properly with ast_free() and no longer causes
MALLOC_DEBUG to freak out.
* When ast_asprintf() fails, set the pointer NULL if
it will be referenced later.
* Fix some memory leaks that were spotted while taking
care of the first two points.
(Closes issue ASTERISK-20135)
reported by Richard Mudgett
Review: https://reviewboard.asterisk.org/r/2071
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371590 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This replaces all calls to alloca() with ast_alloca() which calls gcc's
__builtin_alloca() to avoid BSD semantics and removes all NULL checks
on memory allocated via ast_alloca() and ast_strdupa().
(closes issue ASTERISK-20125)
Review: https://reviewboard.asterisk.org/r/2032/
Patch-by: Walter Doekes (wdoekes)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370642 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_streamfile previously did unconditional seeking on files that broke
playback of formats that don't support that functionality. This patch avoids
the seek that was causing the problem. This regression was introduced in
r158062.
(closes issue ASTERISK-18994)
Patch-by: Timo Teras
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@349731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes the format type check in ast_closestream and
filestream_destructor. Previously a comparison operator was used, but since
audio formats are no longer contiguous (and AST_FORMAT_AUDIO_MASK includes
formats that have a value greater than the video formats), a bitwise AND
operation is used instead. Duplicated code was also moved to filestream_close.
(closes issue ASTERISK-18682)
Reported by: Aldo Bedrij
Tested by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1580/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@344823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After the change in r336294, the new AST_CONTROL_UPDATE_RTP_PEER frame
is sent when a re-invite happens. If we receive a re-invite from a device
the waitstream_core was not aware of the new control frame and would drop
the call.
(closes issue ASTERISK-18610)
Reported by: Kristijan_Vrban
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@339086 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This update adds a new AMI event, TestEvent, which is enabled when the TEST_FRAMEWORK compiler flag is defined. It also adds initial usage of this event to app_voicemail. The TestEvent AMI event is used extensively by the voicemail tests in the Asterisk Test Suite.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@332817 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a cache directory is used, the process is forked and a mv command is executed to move the temporary file to the permanent location. This caused issues with voicemail, where a race condition occurred when the parent expected the file to be in the permanent location prior to the mv command completing. The parent process is now blocked until the mv command completes.
(closes issue ASTERISK-17724)
Reported by: Adiren P.
Tested by: mjordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@326209 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r304096 | seanbright | 2011-01-25 20:24:58 -0500 (Tue, 25 Jan 2011) | 12 lines
Per the man page, setvbuf() must be called before any other operation on an open file.
We use setvbuf() to associate a buffer with a stream, but we have already written
to the open file. This works (by chance) on Linux, but fails on other platforms,
such as OpenSolaris.
(closes issue #16610)
Reported by: bklang
Patches:
setvbuf.patch uploaded by crjw (license 963)
Tested by: bklang, asgaroth, efutch
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@304097 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The purpose of this patch is to eliminate struct ast_callerid since it has
turned into a miscellaneous collection of various party information.
Eliminate struct ast_callerid and replace it with the following struct
organization:
struct ast_party_name {
char *str;
int char_set;
int presentation;
unsigned char valid;
};
struct ast_party_number {
char *str;
int plan;
int presentation;
unsigned char valid;
};
struct ast_party_subaddress {
char *str;
int type;
unsigned char odd_even_indicator;
unsigned char valid;
};
struct ast_party_id {
struct ast_party_name name;
struct ast_party_number number;
struct ast_party_subaddress subaddress;
char *tag;
};
struct ast_party_dialed {
struct {
char *str;
int plan;
} number;
struct ast_party_subaddress subaddress;
int transit_network_select;
};
struct ast_party_caller {
struct ast_party_id id;
char *ani;
int ani2;
};
The new organization adds some new information as well.
* The party name and number now have their own presentation value that can
be manipulated independently. ISDN supplies the presentation value for
the name and number at different times with the possibility that they
could be different.
* The party name and number now have a valid flag. Before this change the
name or number string could be empty if the presentation were restricted.
Most channel drivers assume that the name or number is then simply not
available instead of indicating that the name or number was restricted.
* The party name now has a character set value. SIP and Q.SIG have the
ability to indicate what character set a name string is using so it could
be presented properly.
* The dialed party now has a numbering plan value that could be useful to
have available.
The various channel drivers will need to be updated to support the new
core features as needed. They have simply been converted to supply
current functionality at this time.
The following items of note were either corrected or enhanced:
* The CONNECTEDLINE() and REDIRECTING() dialplan functions were
consolidated into func_callerid.c to share party id handling code.
* CALLERPRES() is now deprecated because the name and number have their
own presentation values.
* Fixed app_alarmreceiver.c write_metadata(). The workstring[] could
contain garbage. It also can only contain the caller id number so using
ast_callerid_parse() on it is silly. There was also a typo in the
CALLERNAME if test.
* Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
number string. ast_callerid_parse() alters the given buffer which in this
case is the channel's caller id number string. Then using
ast_shrink_phone_number() could alter it even more.
* Fixed caller ID name and number memory leak in chan_usbradio.c.
* Fixed uninitialized char arrays cid_num[] and cid_name[] in
sig_analog.c.
* Protected access to a caller channel with lock in chan_sip.c.
* Clarified intent of code in app_meetme.c sla_ring_station() and
dial_trunk(). Also made save all caller ID data instead of just the name
and number strings.
* Simplified cdr.c set_one_cid(). It hand coded the ast_callerid_merge()
function.
* Corrected some weirdness with app_privacy.c's use of caller
presentation.
Review: https://reviewboard.asterisk.org/r/702/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Suppress the warning about unexpected control subclass frames for
AST_CONTROL_CONNECTED_LINE, AST_CONTROL_REDIRECTING, and AST_CONTROL_AOC
in file.c:waitstream_core().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268578 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222878 | russell | 2009-10-08 14:45:47 -0500 (Thu, 08 Oct 2009) | 44 lines
Make filestream frame handling safer by isolating frames before returning them.
This patch is related to a number of issues on the bug tracker that show
crashes related to freeing frames that came from a filestream. A number of
fixes have been made over time while trying to figure out these problems, but
there re still people seeing the crash. (Note that some of these bug reports
include information about other problems. I am specifically addressing
the filestream frame crash here.)
I'm still not clear on what the exact problem is. However, what is _very_
clear is that we have seen quite a few problems over time related to unexpected
behavior when we try to use embedded frames as an optimization. In some cases,
this optimization doesn't really provide much due to improvements made in other
areas.
In this case, the patch modifies filestream handling such that the embedded frame
will not be returned. ast_frisolate() is used to ensure that we end up with a
completely mallocd frame. In reality, though, we will not actually have to malloc
every time. For filestreams, the frame will almost always be allocated and freed
in the same thread. That means that the thread local frame cache will be used.
So, going this route doesn't hurt.
With this patch in place, some people have reported success in not seeing the
crash anymore.
(SWP-150)
(AST-208)
(ABE-1834)
(issue #15609)
Reported by: aragon
Patches:
filestream_frisolate-1.4.diff2.txt uploaded by russell (license 2)
Tested by: aragon, russell
(closes issue #15817)
Reported by: zerohalo
Tested by: zerohalo
(closes issue #15845)
Reported by: marhbere
Review: https://reviewboard.asterisk.org/r/386/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a document describing the language prompt submission process,
licensing terms and other issues related to that process. In addition, it
modifies the sound file searching process to support language codes with
any number of suffices (not limited to just "xx" or "xx_YY"), so that prompts
can be named with gender, customer/company, etc. suffices as well.
(closes issue #15771)
Reported by: jtodd
Patches:
language-criteria.txt uploaded by jtodd
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Someone asked yesterday, "is there a good reason why we can't just put these
modules in Asterisk?". After a brief discussion, as long as the modules are
clearly set aside in their own directory and not enabled by default, it is
perfectly fine.
For more information about why a module goes in addons, see README-addons.txt.
chan_ooh323 does not currently compile as it is behind some trunk API updates.
However, it will not build by default, so it should be okay for now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203785 | russell | 2009-06-26 16:16:39 -0500 (Fri, 26 Jun 2009) | 15 lines
Don't fast forward past the end of a message.
This is nice change for users of the voicemail application. If someone gets a
little carried away with fast forwarding through a message, they can easily
get to the end and accidentally exit the voicemail application by hitting the
fast forward key during the following prompt.
This adds some safety by not allowing a fast forward past the end of a message.
(closes issue #14554)
Reported by: lacoursj
Patches:
21761.patch uploaded by lacoursj (license 707)
Tested by: lacoursj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r200991 | kpfleming | 2009-06-16 12:05:38 -0500 (Tue, 16 Jun 2009) | 11 lines
Improve support for media paths that can generate multiple frames at once.
There are various media paths in Asterisk (codec translators and UDPTL, primarily)
that can generate more than one frame to be generated when the application calling
them expects only a single frame. This patch addresses a number of those cases,
at least the primary ones to solve the known problems. In addition it removes the
broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API
functions, and cleans up various code paths affected by these changes.
https://reviewboard.asterisk.org/r/175/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201056 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem came from the fact that a frame read from a format interpreter
was not freed. Adding a call to ast_frfree fixed this. The explanation for
why this caused the problem is a bit complex, but here goes:
There was a problem in all versions of Asterisk where the embedded frame
of a filestream structure was referenced after the filestream was freed. This
was fixed by adding reference counting to the filestream structure. The refcount
would increase every time that a filestream's frame pointer was pointing to an
actual frame of data. When the frame was freed, the refcount would decrease. Once
the refcount reached 0, the filestream was freed, and as part of the operation,
the open files were closed as well.
Thus it becomes more clear why a missing ast_frfree would cause a reference leak
and cause the files to not be closed. You may ask then if there was a frame leak
before this patch. The answer to that is actually no! The filestream code was
"smart" enough to know that since the frame we received came from a format interpreter,
the frame had no malloced data and thus didn't need to be freed. Now, however, there
is cleanup that needs to be done when we finish with the frame, so we do need to
call ast_frfree on the frame to be sure that the refcount for the filestream is
decremented appropriately.
(closes issue #14384)
Reported by: fiddur
Patches:
14384.patch uploaded by putnopvut (license 60)
Tested by: fiddur, putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173354 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A crash was brought up on the bugtracker. The first run through valgrind
was full of legitimate complaints of uninitialized values in func_timeout when
setting a response timeout. These were fixed but the crash persisted.
A second run through showed the real problem. The reference counting used
for filestreams was incorrect because there were some missing increments
when a frame was read from a format module.
(closes issue #14118)
Reported by: blitzrage
Patches:
14118v2.patch uploaded by putnopvut (license 60)
Tested by: blitzrage
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166267 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Matthew Jordan
Kinsey Moore
Russell Bryant
Richard Mudgett
Mark Michelson
Kevin P. Fleming
Terry Wilson
Leif Madsen
Sean Bright
David Vossel
Tilghman Lesher
Olle Johansson
Matthew Nicholson
Joshua Colp