The modules used strtok(), which is not thread-safe. So it will potentially
segfault when multiple instances are spawned (what e.g. happens on busy
systems).
This patch replaces strtok() with its thread-safe counterpart
strtok_r().
see also https://github.com/rsyslog/rsyslog/issues/1359
The preloaded library causes some side-effect, which we so far
did not find. We try to avoid making CI always fail, and so we
skip the test on FreeBSD for now.
Until now maxDataSize was not set correctly because of the
following order of events.
* MaxMessageSize default value is set.
* MaxDataSize default value is set by maxMessageSize.
* Only now maxMessageSize is set as the configured value.
Because of that, maxDataSize never had the configured maxMessageSize value.
See: https://github.com/rsyslog/rsyslog/issues/1782#issuecomment-352027757
Now maxMessageSize is set before being used by maxDataSize as default, as
described here:
https://github.com/rsyslog/rsyslog/pull/1525#issuecomment-384179393
provide better error messages and make sure errors detected by
the script optimizer are also output if rsyslog aborts early
due to config error.
Also a bit of code improvement (errno etc).
The following errors must be made in rsyslog.conf:
* no action present
* a call statement is used on an undefined ruleset
In this case, rsyslog emits an error message on the missing actions and
then segfaults. Depending on memory layout, it may also continue to run
but do nothing except accepting messages as no action is configured.
This patch make rsyslog properly terminate after the error message. It
is a change in behavior, but there really is no reason why a defunct
instance should be kept running.
closes https://github.com/rsyslog/rsyslog/issues/2399
When a "call" script statement was used with a non-existing ruleset AND
debug logginf was active for rainerscript.c, valgrind complained and
one debug message could potentially be incorrect (stating a queue
where non was).
This was caused by not initializing a variable which was probed in
debug mode before it was set. Non-debug mode was not affected.
see also https://github.com/rsyslog/rsyslog/issues/2399#issuecomment-384890873
if a ruleset queue is in direct mode, a segfault can occur during
rsyslog shutdown. The root cause is that a direct queue does not
have an associated worker thread pool, but the ruleset destructor
does not anticipate that and tries to destruct the worker thread
pool. It needs to do this itself, as otherwise we get a race
between rulesets on shutdown.
This is a regression from
https://github.com/rsyslog/rsyslog/commit/3fbd901b3e6300010
closes https://github.com/rsyslog/rsyslog/issues/2480
When imfile rewrites state files, it does not truncate previous
content. If the new content is smaller than the existing one, the
existing part will not be overwritten, resulting in invalid json.
That in turn can lead to some other failures.
closes https://github.com/rsyslog/rsyslog/issues/2662
