Review https://reviewboard.asterisk.org/r/2580/ tried to fix the mismatch
in memory pools but had a math error determining the buffer size and
didn't address other similar memory pool mismatches.
* Effectively reverted the previous patch to go in the same direction as
trunk for the returned memory pool of ast_bt_get_symbols().
* Fixed memory leak in ast_bt_get_symbols() when BETTER_BACKTRACES is
defined.
* Fixed some formatting in ast_bt_get_symbols().
* Fixed sig_pri.c freeing memory allocated by libpri when MALLOC_DEBUG is
enabled.
* Fixed __dump_backtrace() freeing memory from ast_bt_get_symbols() when
MALLOC_DEBUG is enabled.
* Moved __dump_backtrace() because of compile issues with the utils
directory.
(closes issue ASTERISK-22221)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2778/
........
Merged revisions 397525 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The --version-script,asterisk.exports linker flag (and the module
exports) didn't provide _IO_stdin_used in the list of exported symbols.
That causes some kind of libc compatibility mode to kick in, where
stdio file structures (stdout/stderr) land somewhere else. In the
case of the Sparc, they landed on misaligned memory.
This became apparent first after r376428 (Reorder startup sequence)
when a lot of ast_log's were replaced with fprintf's. Writing to
stderr triggered a SIGBUS. (Compared to x86 and amd64 architectures,
the Sparc is very picky about memory alignment.)
(issue ASTERISK-21763)
(issue ASTERISK-21665)
Reported by: Jeremy Kister
Review: https://reviewboard.asterisk.org/r/2760/
........
Merged revisions 397377 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the file udptl.conf is unavailable at startup, UDPTL will fail to
initialize and while it makes some noise, it isn't immediately
obvious why consumers start to fail when using it. This patch makes
UDPTL load as though an empty config was provided when udptl is
unavailable at startup.
(closes issue ASTERISK-22349)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2773/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If an endpoint fails to include the T38MaxBitRate attribute during negotiation,
Asterisk will negotiate a bit rate of 2400 instead of the ITU recommended
bit rate of 14400. This patch fixes this by making AST_T38_RATE_14400 the
'default' value of the enum by assigning it a value of 0, such that if an
endpoint fails to include the attribute, the default will be 14400.
Note that Walter Doekes included the nice comment in frame.h about why we are
purposefully assigning AST_T38_RATE_14400 a value of 0.
(closes issue ASTERISK-22275)
Reported by: Andreas Steinmetz
patches:
fax-fix.patch uploaded by anstein (License 6523)
........
Merged revisions 397256 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397257 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a From header on an outbound out-of-call SIP MESSAGE were
malformed, the result could crash Asterisk.
In addition, if a From header on an incoming out-of-call SIP
MESSAGE request were malformed, the message was happily accepted
rather than being rejected up front. The incoming message path
would not result in a crash, but the behavior was bad nonetheless.
(closes issue ASTERISK-22185)
reported by Zhang Lei
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397254 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In 1.8, r384779 introduced a regression by retrieving an old dialog and keeping
the old recv address since recv was already set. This has caused a problem when
a proxy is involved since responses to incoming requests from the proxy server,
after an outbound call is established, are never sent to the correct recv
address.
In 11, r382322 introduced this regression.
The fix is to revert that change and always store the recv address on incoming
requests.
Thank you Walter Doekes for helping to point out this error and Mark Michelson
for your input/review of the fix.
(closes issue ASTERISK-22071)
Reported by: Alex Zarubin
Tested by: Alex Zarubin, Karsten Wemheuer
Patches:
asterisk-22071-store-recvd-address.diff by Michael L. Young (license 5026)
........
Merged revisions 397204 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch ensures that CLI commands enabled by DEBUG_FD_LEAKS and
DEBUG_THREADLOCALS are cleaned up properly on exit.
(closes issue ASTERISK-22238)
Reported by: Corey Farrell
Tested by: Corey Farrell
Patches:
debug_cli_unregister.patch uploaded by Corey Farrell
........
Merged revisions 397106 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a single-attribute memory leak that was occurring when the
"required" attribute was not true.
(closes issue ASTERISK-22249)
Reported by: Corey Farrell
Tested by: Corey Farrell
Patches:
xmldoc-free_attr_required.patch uploaded by Corey Farrell
........
Merged revisions 397064 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is not safe to iterate over a macro'd list of ao2 objects, deref them such
that the item's destructor is called, and leave them in the list. The list
macro to iterate over items requires the item to be a valid allocated object
in order to proceed to the next item; with MALLOC_DEBUG on the corruption of
the linked list is caught in the crash.
This patch fixes the invalid access to free'd memory by removing the ao2 item
from the list before de-refing it.
Note that this is a backport of r396915 from Asterisk trunk.
........
Merged revisions 396958 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@396961 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Queue members who happen to be in multiple queues at the same time may not
have any wrap up time. This problem occurred due to a code change in Asterisk
11.3.0 that unified device state tracking of Queue members in multiple
Queues (which fixed some other problems, but unfortunately caused this one).
This patch fixes the behavior by having the is_member_available function
check the queue's wrap up time and the time of the member's last call, such
that for a particular queue, the member won't be considered available if their
last call is within the wrap up time.
(closes issue ASTERISK-22189)
Reported by: Tony Lewis
Tested by: Tony Lewis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@396948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When r382230 added an option to not denoise the MeetMe conference (if a user
had a channel whose format's sample rate changed frequently, for example),
the value added was the maximum allowed value for the constants that define
the options for MeetMe in 1.8. Not so in 11 - unfortunately, the option
CONFFLAG_DONT_DENOISE conflicts with CONFFLAG_INTROUESR_VMREC. This patch
fixes that, and also tweaks one of the way in which the constants was
declared for consistency.
Thanks to Tony Mountifield for pointing out the problem and solution.
(closes issue ASTERISK-22269)
Reported by: Tony Mountifield
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@396944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Depending on certain conditions it was possible for the hashtab counting thread
to starve other threads, preventing them from executing in the expected fashion.
This change adds a sleep to allow the others to do what they need to do. While
this doesn't thrash the hashtab as much as previously, it at least works.
(closes issue ASTERISK-22276)
Reported by: Matt Jordan
........
Merged revisions 396619 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@396620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a peer is used in a register line and TLS is defined as the transport, the
registration fails since the transport on the dialog is never set properly
resulting in UDP being used instead of TLS.
This patch sets the dialog's transport based on the transport that was defined
in the register line. If the register line does not specify a transport, the
parsing function for the register line always defaults back to UDP.
(closes issue ASTERISK-21964)
Reported by: Doug Bailey
Tested by: Doug Bailey
Patches:
asterisk-21964-set-reg-dialog-transport.diff
by Michael L. Young (license 5026)
........
Merged revisions 396240 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@396248 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
Restore Extra Line Break Between Peers When Running AMI Action SIPPeers
The commit (r387133) for fixing ASTERISK-21466 accidentally removed an extra
line break between the peers returned by the AMI action SIPPeers. This
results in some parsers breaking because they expect this extra line break.
This patch restores that extra line break.
(closes issue ASTERISK-22239)
Reported by: Jacek Konieczny
Tested by: Jacek Konieczny, Michael L. Young
Patches:
asterisk-ami_sippeers_separator.patch by Jacek Konieczny (license 6298)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@396237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch notes that libuuid is now a dependency for res_rtp_asterisk; this
was introduced in between 11.4.0 and 11.5.0 to resolve a dependency for
pjproject, which res_rtp_asterisk uses for ICE/STUN/TURN support.
It also removes a conflicting note from CHANGES. While support for playing
prompts to the first participant was added for app_queue, it was disabled
by default and an option added to enable it. That was properly noted in the
UPGRADE.txt file.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@395020 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch cleans up documentation in func_channel for the following items:
* rtpsource
* secure_signaling
* secure_media
* various OOH323 parameters
(closes issue ASTERISK-20969)
Reported by: snuffy
patches:
func_chan-update.diff uploaded by snuffy (License 5024)
........
Merged revisions 394980 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@394981 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ring tone provided in the sample indications.conf was incorrect. This patch
modifies the sample ring tone to be what it should:
ring = 425/400,0/200,425/400,0/2000
This brings it in line with the tone definition in DAHDI 2.7.0. (zonedata.c)
(closes issue ASTERISK-21997)
Reported by: Filip Jenicek
patches:
malaysia_ring.patch uploaded by phill (License 6277)
........
Merged revisions 394940 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@394941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch modifies parsing of cookies in Asterisk's http server by doing an
explicit comparison of the "Cookie" header instead of looking at the first
6 characters to determine if the header is a cookie header. This avoids
parsing "Cookie2" headers and overwriting the previously parsed "Cookie"
header.
Note that we probably should be appending the cookies in each "Cookie"
header to the parsed results; however, while clients can send multiple
cookie headers they never really do. While this patch doesn't improve
Asterisk's behavior in that regard, it shouldn't make it any worse either.
Note that the solution in this patch was pointed out on the issue by the
issue reporter, Stuart Henderson.
(closes issue ASTERISK-21789)
Reported by: Stuart Henderson
Tested by: mjordan, Stuart Henderson
........
Merged revisions 394899 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@394900 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch updates the realtime SQL scripts with an entry that will create the
queue_log table. This brings the PostgreSQL scripts inline with the MySQL
scripts, with respect to what tables they will create.
(closes issue ASTERISK-21021)
Reported by: Eugene
patches:
queue_log.sql uploaded by varnav (license 6360)
........
Merged revisions 394896 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@394897 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If there is an error streaming an audio file, the current return status makes it
difficult for an AGI script to determine that there was an error with the audio
file.
This patches changes the result to return -1 and the function returns
RESULT_FAILURE instead of RESULT_SUCCESS. From looking at other parts of
res_agi, this would appear to be the proper way to handle an error.
(closes issue ASTERISK-21903)
Reported by: Ariel Wainer
Tested by: Ariel Wainer
Patches:
asterisk-21903-return-stream-res_1.8.diff
by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2625/
........
Merged revisions 394640 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@394641 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When QUEUE_MEMBER is used and the member specified is not in the queue,
Asterisk provides an ERROR message that indicates that the option specified
is not valid. This patch now properly displays an ERROR message that the
member is not in the queue if an interface is specified.
(closes issue ASTERISK-21980)
Reported by: Avraam David
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@394345 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is not apparent to the average user that the PASSTHRU function should not
be passed as ${PASSTHRU(string)} but just as PASSTHRU(string) to functions
which take a variable name and not its contents.
This patch clarifies the behavior in the documentation and provides an example.
(closes issue ASTERISK-21717)
Reported by: Richard Miller
patches:
func_strings.diff uploaded by Richard Miller (license 5685)
........
Merged revisions 394302 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@394303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
from mixing different variants or general MFC-R2 settings within the same E1 line.
Most users do not have a problem with this since MFC-R2 lines are usually fractional E1s, or
the whole E1 has the same country variant and R2 settings.
In Venezuela however is common to have inbound MFC-R2 and outbound DTMF-R2 within the same E1.
This fix now properly parses the chan_dahdi.conf file to generate a new openr2 context every
time a new channel => section is found and the configuration was changed.
(closes issue ASTERISK-21117)
Reported by: Rafael Angulo
Related Elastix issue: http://bugs.elastix.org/view.php?id=1612
........
Merged revisions 394106 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@394173 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SLA code within app_meetme was written before asotbj2 had been
merged into Asterisk. Worse, support for reloads did not exist at first
and was added later as a bolt-on feature. I knew at the time that
reloading was not safe at all while SLA was in use, so the reload would
be queued up to execute when the system was idle. Unfortunately, this
approach was still prone to errors beyond the fact that this was the
only place in Asterisk where configuration was not reloaded
instantly when requested.
This patch converts various SLA objects to be reference counted objects
using astobj2. This allows reloads to be processed while the system is
in use. The code ensures that the objects will not disappear while one
of the other threads is using them. However, they will be immediately
removed from the global trunk and station containers so no new calls
will use them if removed from configuration.
Review: https://reviewboard.asterisk.org/r/2581/
........
Merged revisions 393928 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@393929 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes the following memory leaks:
* http.c: The structure containing the addresses to bind to was not being
deallocated when no longer used
* named_acl.c: The global configuration information was not disposed of
* config_options.c: An invalid read was occurring for certain option types.
* res_calendar.c: The loaded calendars on module unload were not being
properly disposed of.
* chan_motif.c: The format capabilities needed to be disposed of on module
unload. In addition, this now specifies the default options for the
maxpayloads and maxicecandidates in such a way that it doesn't cause the
invalid read in config_options.c to occur.
(issue ASTERISK-21906)
Reported by: John Hardin
patches:
http.patch uploaded by jhardin (license 6512)
named_acl.patch uploaded by jhardin (license 6512)
config_options.patch uploaded by jhardin (license 6512)
res_calendar.patch uploaded by jhardin (license 6512)
chan_motif.patch uploaded by jhardin (license 6512)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@392810 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The config framework options should not be registered multiple times.
Instead the configuration just needs to be reprocessed by the config
framework.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@391700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The WebSocket code would allocate, on the stack, a string large enough
to hold a key provided by the client, and the WEBSOCKET_GUID. If the key
is NULL, this causes a segfault. If the key is too large, it could
overflow the stack.
This patch checks the key for NULL and checks the length of the key to
avoid stack smashing nastiness.
(closes issue ASTERISK-21825)
Reported by: Alfred Farrugia
Tested by: Alfred Farrugia, David M. Lee
Patches:
issueA21825_check_if_key_is_sent.patch uploaded by Walter Doekes (license 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@391560 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes two memory leaks:
* When we load a module with the LOAD_PRIORITY flag, we remove its entry from
the load order list. Unfortunately, we don't free the memory associated with
entry in the list. This patch corrects that and properly frees the memory
for the module in the list.
* When adding a custom format (such as SILK or CELT), the routine for adding
the format was leaking a reference. RAII_VAR cleans this up properly.
........
Merged revisions 391489 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@391507 65c4cc65-6c06-0410-ace0-fbb531ad65f3
