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/branches/1.4@222878 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@200991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With these changes, for a module to export symbols into the global namespace, it must have *both* the AST_MODFLAG_GLOBAL_SYMBOLS flag and a linker script that allows the linker to leave the symbols exposed in the module's .so file (see res_odbc.exports for an example).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@182802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During some code analysis, I found that calling ast_rtp_codec_setpref() on an ast_rtp session does not work as expected; it does not adjust the smoother that may on the RTP session, in fact it summarily drops it, even if it has data in it, even if the current format's framing size has not changed. This is not good.
This patch changes this behavior, so that if the packetization size for the current format changes, any existing smoother is safely updated to use the new size, and if no smoother was present, one is created. A new API call for smoothers, ast_smoother_reconfigure(), was required to implement these changes.
Review: http://reviewboard.digium.com/r/184/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@180372 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During iax2 call negotiation, supported codecs are passed in an Information Element containing a 2 byte field where each bit correlates to a specific codec. In 1.4 only audio codec bits 0-12 are defined, leaving bits 13-15 undefined. By default all bits are enabled unless specified otherwise. Since its a 2 byte field and 13-15 are not defined, these bits are never turned off. In trunk, bits 13-15 are defined, which means 1.4 is advertising support for codecs it does not have when talking to trunk. I fixed this by adding #define for undefined audio codec bits. These bits are then removed from iax2's full bandwidth capabilities.
(closes issue #14283)
Reported by: jcovert
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@177696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
frame in a freed ast_filestream. This patch makes use of the
ao2 functions to make sure that we do not free an ast_filestream
structure until the embedded ast_frame has been "freed" as well.
(closes issue #13496)
Reported by: fst-onge
Patches:
filestream_frame_1_4.diff uploaded by putnopvut (license 60)
Tested by: putnopvut
Closes AST-89
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158126 65c4cc65-6c06-0410-ace0-fbb531ad65f3
referenced, leading to memory corruption and eventual crashes. This code change ensures
that the dsp is freed when we are finished with the frame. This change is very similar
to a change Russell made with translators back a month or so ago.
(closes issue #11999)
Reported by: destiny6628
Patches:
11999.patch uploaded by putnopvut (license 60)
Tested by: destiny6628, victoryure
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114207 65c4cc65-6c06-0410-ace0-fbb531ad65f3
len field in an ast_frame of audio was wrong when G.722 is in use. The len field
represents the number of ms of audio that the frame contains. It would have
set the value to be twice what it should be.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@105932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the caller's codec is in our codec list, move it to the top to avoid transcoding.
(closes issue #10500)
Reported by: stevedavies
Patches:
iax-prefer-current-codec.patch uploaded by stevedavies (license 184)
iax-prefer-current-codec.1.4.patch uploaded by stevedavies (license 184)
Tested by: stevedavies, pj, sheldonh
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@99004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
output on issue #11698.
The issue here is that it is possible for an instance of a translator to get
destroyed while the frame allocated as a part of the translator is still being
processed. Specifically, this is possible anywhere between a call to ast_read()
and ast_frame_free(), which is _a lot_ of places in the code. The reason this
happens is that the channel might get masqueraded during this time. During a
masquerade, existing translation paths get destroyed.
So, this patch fixes the issue in an API and ABI compatible way. (This one is
for you, paravoid!)
It changes an int in ast_frame to be used as flag bits. The 1 bit is still used
to indicate that the frame contains timing information. Also, a second flag has
been added to indicate that the frame came from a translator. When a frame with
this flag gets released and has this flag, a function is called in translate.c to
let it know that this frame is doing being processed. At this point, the flag gets
cleared. Also, if the translator was requested to be destroyed while its internal
frame still had this flag set, its destruction has been deffered until it finds out
that the frame is no longer being processed.
Admittedly, this feels like a hack. But, it does fix the issue, and I was not able
to think of a better solution ...
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@98943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
for uses in cases where you *know* that it will do no good. This patch was
inspired by file for use in some work of his on mixmonitor/chanspy.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@41958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are some situations in Asterisk where ast_frame and/or iax_frame
structures are rapidly allocatted and freed (at least 50 times per second
for one call).
This code significantly improves the performance of ast_frame_header_new(),
ast_frdup(), ast_frfree(), iax_frame_new(), and iax_frame_free() by keeping
a thread-local cache of these structures and using frames from the cache
whenever possible instead of calling malloc/free every time.
This commit also converts the ast_frame and iax_frame structures to use the
linked list macros.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@41278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
split support for G726-32 into RFC3551 and AAL2 packing orders, since both are in use
change "G726-32" to be RFC3551 packing order, in spite of devices that use AAL2 order with this MIME type
add ability to directly transcode between packing orders
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@37494 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a new implementation of a fixed size jitterbuffer, as well as support for the
existing adaptive jitterbuffer implementation. (issue #3854, Slav Klenov)
Thank you very much to Slav Klenov of Securax and all of the people involved
in the testing of this feature for all of your hard work!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@31052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
const-ify some more APIs
remove 'type' field from ast_channel, in favor of the one in the channel's tech structure
allow string field module users to specify the 'chunk size' for pool allocations
update chan_alsa to be compatible with recent const-ification patches
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@9060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
cleanup code in ast_read()
add AST_FRAME_DTMF_BEGIN and AST_FRAME_DTMF_END so that variable-length DTMF events can be supported
teach chan_zap to send DTMF_BEGIN and DTMF_END when appropriate
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@8850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This should prevent us from unintentionally changing variable
values when they're returned from pbx_builtin_getvar_helper.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@7304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
