| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This actually at compile time disables a lot of debug code, resulting
in some speedup (but serious loss of debugging capabilities)
|
|
|
|
|
|
|
|
|
|
|
| |
if rsyslog was set to auto-background (thus fork, the default) and debug
mode to stdout was enabled, debug messages ended up in the first log file
opened. Currently, stdout logging is completely disabled in forking mode
(but writing to the debug log file is still possible). This is a change
in behaviour, which is under review. If it causes problems to you,
please let us know.
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
runtime/debug.h
runtime/obj.c
runtime/parser.h
runtime/wti.h
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
ChangeLog
tests/Makefile.am
tests/sndrcv_drvr.sh
tools/syslogd.c
|
| |
| |
| |
| |
| | |
This is close to a bug, but I'd consider the ability to background
in this mode a new feature...
|
|/
|
|
|
|
|
|
| |
support for enhancing probability of memory addressing failure by
using non-NULL default value for malloced memory (optional, only if
requested by configure option). This helps to track down some
otherwise undetected issues within the testbench and is expected
to be very useful in the future.
|
| |
|
|
|
|
|
| |
... seems to work on quick testing, but needs a far more testing
and improvement. Good milestone commit.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
There exists a race condition that can lead to a segfault. Thanks
go to vbernetr, who performed the analysis and provided patch, which
I only tweaked a very little bit.
|
| |
| |
| |
| |
| |
| | |
This enables us to use more efficient calling conventions and
also helps us keep the on-disk structure of a msg object more
consistent in future releases.
|
| |
| |
| |
| |
| |
| |
| |
| | |
cleaned up previous code and redid it in a way that makes
it much easier to extend it
also added a new macro DBGPRINTF which is a performance-optimzed
version of dbgprintf
|
|/
|
|
|
|
|
| |
There was a wrong order of mutex lock operations. It is hard to
believe that really caused problems, but in theory it could and with
threading we often see that theory becomes practice if something is only
used long enough on a fast enough machine with enough CPUs ;)
|
|
there are still some files left which could go into the
runtime, but I think we will delete most of them once we
are done with the full modularization.
|