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.
