if the tail of message similar to replacement string. Example:
msg: 1234567890
replacement: 8906
the last N (amount of similar symbols in tail of message and the begin of replacement,
in current example = 3) will never be assigned in dst message. And will contain a garbage.
As longer replacement string as more garbage will be in dst message instead of a required
src tail.
The length of dst message is right. The tail of dst message filled with garbage.
Because of memory for dst message is allocated with right size, but didn't filled if
the tail of message partially equals to a beginning of a replacement string.
commit 0fbe873438e introduced an unchecked realloc, which under
extreme conditions (total out-of-memory condition) could lead to
a NULL pointer access. This commit fixes the issue be avoiding the
need for realloc() in the first place.
Note that commit 0fbe873438e was merged today, so there is no
problem in any released code.
omkafka emits many useful operational status messages only to the debug
log. After careful review, we have exposed many of these as user error
and warning message (ex: librdkafka queue full, so user knows why we
suspend the plugin temporarily). This may have made the module too
chatty. If so, one can always filter out messages via configuration. And
if we really went overboard, we can undo those parts with the next
release. So IMHO it's better to give a bit more than less, as this
definitely eases troubleshooting for users.
closes https://github.com/rsyslog/rsyslog/issues/2314
The currently done buffer modification (add of '\0') is bad, especially when
multiple threads access the same string. It is not really an issue that needs
to be urgently fixed, as always the same data is written. However, among others,
it will pollute the thread debugger and as such prevent more elaborate automatted
tests.
closes https://github.com/rsyslog/rsyslog/issues/1993
The last commit (yesterday) did not properly convey when we actually
needed to cancel a thread. This commit corrects this and also
provides better information on the actual cancel operation and
some tipps for the user on how to solve it (timeout mentioned).
some of the counters were defined as int (32 bit) vs. intctr_t (64 bit).
On some platforms "long" seems to be 64bit, and getrusage() provides
what we store as int via long. So this caused truncation and/or overflow.
This had undefined effects. Most often, everything worked fine
for values smaller than 2^31 but sometimes we got negative values.
closes https://github.com/rsyslog/rsyslog/issues/1517
this helps to diagnose issue - unfortunately we need more
work to ensure that the messages always make it to the user. This
is a start and hopefully useful at least for the testbench, possibly
more.
The previous settings did not make much sense (same set of source
files checked) and also made us violate our Travis permitted runtime.
So rather than splitting the test into 2 VMs, we just remove one of
the static analyzer runs.
This internal state was improperly handled and most probably caused
(hard to see) issues when action instances were run on multiple worker
threads. It looks like the state variable was forgotten to move over
to worker state when action workers were introduced. This patch
fixes that.
closes https://github.com/rsyslog/rsyslog/issues/2046
... because we know they sometimes fail due to a confirmed bug
inside imfile. These need to be re-enabled once the bug is fixed.
see also https://github.com/rsyslog/rsyslog/issues/2271
on slow testbench machines, we may cancel processing where this is not
desired. Most importantly, this could lead to small memorey leaks
due to the thread cancellation (which are then expected!) that then
lead to false test failures.
omkafka has several issue if multiple worker instances are used. This commit
actually make the module use a single worker thread at max. Reasoning:
Librdkafka creates background threads itself. So omkafka basically needs to move
memory buffers over to librdkafka, which then does the heavy hauling. As such, we
think that it is best to run max one wrkr instance of omkafka -- otherwise we just
get additional locking (contention) overhead without any real gain. As such,
we use a global mutex for doAction which ensures only one worker can be active
at any given time. That mutex is also used to guard utility functions (like
tryResume) which may also be accessed by multiple workers in parallel.
Note: shall this method be changed, the kafka connection/suspension handling needs
to be refactored. The current code assumes that all workers share state information
including librdkafka handles.
closes https://github.com/rsyslog/rsyslog/issues/2313
if kafka produce fails when resubmitting messages, the message object
is duplicated. This potentially leads to a mem leak or message duplication
(not fully checked yet).
The error message regularly occurs if no kafka/zk instance is running,
which should be the case at start of test. However, the message
tends to make think reviewers that it is a real error. So we now
hide it.
On Ubuntu 16, we do not have libczmq 4, but omczmq obviously builds
fine with 3.0.2, so this seems to be the actual requirement. If that
works, I'll settle for now as I am finally totally confused on what
happens here. I have asked for help from those in the know, but
if we do not get a definitive answer, it'll stay so that it works
for us -- after all this is a contributed module...
closes https://github.com/rsyslog/rsyslog/issues/872
