(closes issue #11243)
Reported by: whiskerp
Patches:
11243-maybe-asm.diff uploaded by qwell (license 4)
Tested by: Seggy (IRC)
Note: While I did write this patch, I would not have found this if fossil
had not reported and fixed issue #12253. A huge thanks to him for helping
to (indirectly) find the problem here.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@111856 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
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
for gsm.h as well. Furthermore, when checking for this header, it may be
located in a gsm/ sub directory, so check for that, as well.
(issue #8773)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@52997 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- with AST_DEVMODE, building codecs/lpc10 fails because of lots
of warnings, and the configure step in editline fails as well.
Fix this by removing the -Werror in these steps.
- on FreeBSD (but probably on other platforms as well), the final
link of asterisk fails because AST_LIBS was not exported to the
subdirs Makefiles. Add a proper fix in the top-level Makefile
(a possible alternative way is to add "export AST_LIBS" near
the beginning of the file).
With this fix, i believe that some of the platform-specific
conditionals in main/Makefile are redundant (because they should
be already dealt with in the top level Makefile) but i don't
have a platform to check.
Merging to head will happen in a moment.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@44080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- restructured build tree and makefiles to eliminate recursion problems
- support for embedded modules
- support for static builds
- simpler cross-compilation support
- simpler module/loader interface (no exported symbols)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
astmm support and astmm doesn't get really upset and complain that it is being
asked to free memory that was never allocated
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38271 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I don't particular like the approach, which basically tries to exclude the file based on
NOT being in a list of arches. This, IMHO, is backwards, it should be a list of AMD arches
instead. "Better to light a candle, than to curse the darkness", is apropo here. But since I don't
have an exhaustive list of what those arches could be, I leave as-is for now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38187 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
