https://origsvn.digium.com/svn/asterisk/branches/10
................
r334954 | rmudgett | 2011-09-08 17:28:56 -0500 (Thu, 08 Sep 2011) | 17 lines
Merged revisions 334953 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r334953 | rmudgett | 2011-09-08 17:27:40 -0500 (Thu, 08 Sep 2011) | 10 lines
Fix crash with res_fax when MALLOC_DEBUG and "core stop gracefully" are used.
Asterisk crashes if MALLOC_DEBUG is enabled when res_fax tries to
unregister its logger level.
* Make ast_logger_unregister_level() use ast_free() instead of free().
When MALLOC_DEBUG is enabled, ast_free() does not degenerate into a call
to free(). Therefore, if you allocated memory with a form of ast_malloc
you must free it with ast_free.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@334955 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r331654 | kmoore | 2011-08-12 11:21:37 -0500 (Fri, 12 Aug 2011) | 19 lines
Merged revisions 331649 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r331649 | kmoore | 2011-08-12 11:20:25 -0500 (Fri, 12 Aug 2011) | 12 lines
Logger does not warn of failure to open logging channels
Currently, logger only prints an error message to stderr when it fails to open
a logger channel where many users will not see it because the logger lock is
held. The alternative provided by this patch is to log the error to all
attached consoles in the hopes that it will be easier to see. Additionally,
this patch prevents the failed logger channel from being added to the list
where it would silently fail on each call to the Asterisk logger.
(closes issue ASTERISK-16231)
Review: https://reviewboard.asterisk.org/r/1338
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@331657 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r331462 | rmudgett | 2011-08-10 15:41:35 -0500 (Wed, 10 Aug 2011) | 37 lines
Merged revisions 331461 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r331461 | rmudgett | 2011-08-10 15:29:59 -0500 (Wed, 10 Aug 2011) | 30 lines
Output of queue log not started until logger reloaded.
ASTERISK-15863 caused a regression with queue logging. The output of the
queue log is not started until the logger configuration is reloaded.
* Queue log initialization is completely delayed until the first message
is posted to the queue log system. Including the initial opening of the
queue log file.
* Fixed rotate_file() ROTATE strategy to give the file just rotated out to
the configured exec function after rotate. Just like the other strategies.
* Fixed logger reload to always post the queue reload entry instead of
just if there is a queue log file.
* Refactored some code to eliminate some redundancy and to reduce stack
utilization.
(closes issue ASTERISK-17036)
JIRA SWP-2952
Reported by: Juan Carlos Valero
Patches:
jira_asterisk_17036_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: rmudgett
(closes issue ASTERISK-18208)
Reported by: Christian Pinedo
Review: https://reviewboard.asterisk.org/r/1333/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@331463 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r307092 | qwell | 2011-02-08 15:24:01 -0600 (Tue, 08 Feb 2011) | 9 lines
Fix issue with verbose messages not showing on remote console.
This code was reworked recently, and since the logchannel list hadn't been
created yet at this point, and it was a verbose message, it was being dropped
on the floor. Now it'll continue on to where it should be handled.
(closes issue #18580)
Reported by: pabelanger
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307097 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r298960 | tilghman | 2010-12-17 17:52:04 -0600 (Fri, 17 Dec 2010) | 20 lines
Merged revisions 298957 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r298957 | tilghman | 2010-12-17 17:30:55 -0600 (Fri, 17 Dec 2010) | 13 lines
Merged revisions 298905 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r298905 | tilghman | 2010-12-17 15:40:56 -0600 (Fri, 17 Dec 2010) | 6 lines
Let Asterisk find better backtrace information with libbfd.
The menuselect option BETTER_BACKTRACES, if enabled, will use libbfd to search
for better symbol information within both the Asterisk binary, as well as
loaded modules, to assist when using inline backtraces to track down problems.
Review: https://reviewboard.asterisk.org/r/1055/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@298961 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Already had the pthread ID which is not the same. The most obvious enhancement
is in the "core show threads" output. As stated in the utils header, if the
platform isn't supported -1 is reported (instead of the process ID previously).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@298137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r266142 | tilghman | 2010-05-26 16:11:44 -0500 (Wed, 26 May 2010) | 14 lines
Use sigaction for signals which should persist past the initial trigger, not signal.
If you call signal() in a Solaris signal handler, instead of just resetting
the signal handler, it causes the signal to refire, because the signal is not
marked as handled prior to the signal handler being called. This effectively
causes Solaris to immediately exceed the threadstack in recursive signal
handlers and crash.
(closes issue #17000)
Reported by: rmcgilvr
Patches:
20100526__issue17000.diff.txt uploaded by tilghman (license 14)
Tested by: rmcgilvr
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Nick Lewis pointed out that the patch as committed wouldn't actually include
dynamic logger levels, which was missed by the other reviewers. Thanks!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now that Asterisk modules can dynamically create and destroy logger levels
on demand, it's useful to be able to configure a logger channel (console,
file, whatever) to be able to accept log messages from *all* levels, even
levels created dynamically. This patch adds support for this, by allowing
the '*' level name to be used in logger.conf.
Review: https://reviewboard.asterisk.org/r/663/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264160 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The logic here was reversed as ast_safe_system returns -1 on error and not on
success. Fix suggested by reporter.
(closes issue #15667)
Reported by: loic
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CEL is the new system for logging channel events. This was inspired after
facing many problems trying to represent what is possible to happen to a call
in Asterisk using CDR records. For more information on CEL, see the built in
HTML or PDF documentation generated from the files in doc/tex/.
Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard
work developing this code. Also, thanks to Matt Nicholson (mnicholson) and
Sean Bright (seanbright) for their assistance in the final push to get this
code ready for Asterisk trunk.
Review: https://reviewboard.asterisk.org/r/239/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since the message structure is allocated using ast_calloc_with_stringfields we do not need to
free the memory used for the stringfields as it will get freed when the message structure is.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the ability for modules to dynamically create logger levels for their own use; these are named levels just like the built-in levels, and can be directed to any destination that the logger can send any level to, by including their names in logger.conf.
Review: https://reviewboard.asterisk.org/r/244/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@194610 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) If MALLOC_DEBUG is used when concurrently using ast_backtrace, the free()
used in that routine will trigger an error, because the memory was allocated
internally to libc, where we could not intercept that call to wrap it.
Therefore, it's not memory we knew about, and the free is reported as an
error.
2) Now that channels are objects, the old hack of initializing a channel
to all zeroes no longer works, since we may try to call something like
ast_channel_lock() within a function on that reference. In that case, it's
reported as an error, because the pointer isn't an object reference.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@194101 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193193 | kpfleming | 2009-05-08 09:03:28 -0500 (Fri, 08 May 2009) | 7 lines
Make absolute paths for logger channels work properly
(Note: This is not a new feature, it was previously undocumented and broken.)
The Asterisk logger has a feature to support absolute pathnames for logger channels, but the code implementing the feature was broken. This has been fixed, and the absolute path feature is now documented in the sample logger.conf.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@193194 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In discussions today at the Europe Asterisk Developer Meet-Up, we determined that
the event_log was used in only 9 places in the entire tree, and really was not needed
at all. The users have been converted to use LOG_NOTICE, or the messages have been
removed since other messages were already in place that provided the same information.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This code was copy-and-pasted without properly changing references to event_rotate into queue_rotate, so under some conditions the log rotation would rotate queue_log even though it was not necessary.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191775 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(inspired by this evening's Toronto Asterisk Users Group meeting and previous dicussions amongst various community members)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187269 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I was finding that on my dev box, occasionally attempting to "stop now" in
trunk would cause Asterisk to hang. I traced this to the fact that the logger
thread was waiting on a condition which had already been signalled. The logger
thread also need to be sure to check the value of the close_logger_thread variable.
The close_logger_thread variable is only checked when the list of logmessages is empty.
This allows for the logger thread to print and free any pending messages before exiting.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
------------------------------------------------------------------------
r159808 | kpfleming | 2008-11-29 10:58:29 -0600 (Sat, 29 Nov 2008) | 7 lines
update dev-mode compiler flags to match the ones used by default on Ubuntu Intrepid, so all developers will see the same warnings and errors
since this branch already had some printf format attributes, enable checking for them and tag functions that didn't have them
format attributes in a consistent way
------------------------------------------------------------------------
in addition:
move some format attributes from main/utils.c to the header files they belong in, and fix up references to the relevant functions based on new compiler warnings
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@159818 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in 1.6.1 (as compared to 1.6.0 and versions of 1.4), this change also
deprecates the use of Asterisk with FreeBSD 4, given the central use of va_copy
in core functions. va_copy() is C99, anyway, and we already require C99 for
other purposes, so this isn't really a big change anyway. This change also
simplifies some of the core ast_str_* functions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@157639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
this commit, only the logger thread's PID would
be printed.
(closes issue #13150)
Reported by: atis
Patches:
log_pid.diff uploaded by putnopvut (license 60)
Tested by: eliel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133448 65c4cc65-6c06-0410-ace0-fbb531ad65f3
They want (char *)NULL as sentinel.
An example is OpenBSD (confirmed on 4.3) that ships with gcc 3.3.4
This commit introduces a contstant SENTINEL which is declared as:
#define SENTINEL ((char *)NULL)
All places I could test compile on my openbsd system are converted.
Update CODING-GUIDELINES to tell about this constant.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@124127 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a deadlock is detected, then the typical lock information will be
printed along with a backtrace of the stack for the offending threads.
Use of this requires compiling with DETECT_DEADLOCKS and having glibc
installed.
Furthermore, issuing the "core show locks" CLI command will print the
normal lock information as well as a backtraces for each lock. This
requires that DEBUG_THREADS is enabled and that glibc is installed.
All the backtrace features may be disabled by running the configure
script with --without-execinfo as an argument
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@118173 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Until this change, all verbose messages in Asterisk's log files reported logger.c
as the source of the message.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@117693 65c4cc65-6c06-0410-ace0-fbb531ad65f3
equivalent to the check done by ast_verb, I wrote a macro, VERBOSITY_LEVEL, which does this
check. I did a quick look in the source and used this macro in some places where option_verbose
was used.
I also converted some verbose messages in logger.c to use ast_verb instead of ast_verbose.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
build times - tested, there is no measureable difference before and
after this commit.
In this change:
use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h
Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.
Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better.
For the time being I have left alone second-level directories
(main/db1-ast, etc.).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents modifying the strings in the stored variables,
and catched a few instances where this was actually done.
Given the differences between trunk and 1.4 (and the fact that this
is effectively an API change) it is better to fix 1.4 independently.
These are
chan_sip.c::sip_register()
chan_skinny.c:: near line 2847
config.c:: near line 1774
logger.c::make_components()
res_adsi.c:: near line 1049
I may have missed some instances for modules that do not build here.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- the *_CURRENT macros no longer need the list head pointer argument
- add AST_LIST_MOVE_CURRENT to encapsulate the remove/add operation when moving entries between lists
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77380 | mmichelson | 2007-07-26 15:35:17 -0500 (Thu, 26 Jul 2007) | 7 lines
Fixes to get ast_backtrace working properly. The AST_DEVMODE macro was never defined so the majority of ast_backtrace never
attempted compilation. The makefile now defines AST_DEVMODE if configure was run with --enable-dev-mode. Also, changes were
made to acccomodate 64 bit systems in ast_backtrace.
Thanks to qwell, kpfleming, and Corydon76 for their roles in allowing me to get this committed
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77381 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: bbryant
Patches:
20070720__core_debug_by_file.patch uploaded by bbryant (license 36)
(with some modifications by me)
Tested by: russell, bbryant
This set of changes introduces the ability to set the core debug or verbose
levels on a per-file basis. Interestingly enough, in 1.4, you have the ability
to set core debug for a single file, but that functionality was accidentally
lost in the conversion of the CLI commands to the new format.
This patch improves upon what was in 1.4 by letting you set it for more than 1
file, and by also supporting verbose.
*** Janitor Project ***
This patch also introduces a new macro, ast_verb(), which is similar
to ast_debug(). Setting the per file verbose value only works for messages that
use this macro. Converting existing uses of ast_verbose() can be done like:
if (option_debug > 2)
ast_verbose(VERBOSE_PREFIX_3 "Something useful\n");
...
ast_verb(3, "Something useful\n");
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@76555 65c4cc65-6c06-0410-ace0-fbb531ad65f3
renaming them to ast_str ... and putting the
struct ast_threadstorage pointer into the struct ast_str.
This makes the code a lot more readable.
At this point we can use these routines also to
replace ast_build_string().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@48510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
be called for each thread specific object after they are allocated. Note that
there was already the ability to define a custom cleanup function. Also, if
the custom cleanup function is used, it *MUST* call free on the thread
specific object at the end. There is no way to have this magically done that
I can think of because the cleanup function registered with the pthread
implementation will only call the function back with a pointer to the
thread specific object, not the parent ast_threadstorage object.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@45623 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
Richard Mudgett
Alec L Davis
Kinsey Moore
Jason Parker
Paul Belanger
Tilghman Lesher
Jeff Peeler
Russell Bryant
Brett Bryant
Kevin P. Fleming
Leif Madsen
Sean Bright
Joshua Colp
Mark Michelson
Matthew Nicholson
Eliel C. Sardanons
Terry Wilson
Luigi Rizzo
Michiel van Baak
Olle Johansson
Steve Murphy
Matt O'Gorman