access to the Linux-like ratelimiter was not properly synchronized, and
the system rate-limiter was not using it in any case.
This could lead to the rate-limit settings not being properly
respected, but no "hard error".
During e.g. shutdown it could happen that a worker thread was started
and immediately be requested to terminate. In such situations there was
a race the prevented proper initialization. This could lead to follow-on
problems.
We believe (but could not proof) that this also could lead to a hang of
the termination process. Thus we claim to close an issue tracker down
here below, but are not 100% certain it really closes it (we hope for
user feedback on this). In any case, the thread debuger showed invalid
operations and this has been fixed, so it is useful in any case.
closes https://github.com/rsyslog/rsyslog/issues/1959
During shutdown of a tcpsrv, a race could occur, resulting in
a hang on shutdown of rsyslog as whole.
Detected via valgrind's helgrind thread debugger.
if a file cannot be opened but would need to be for the crypto provider
to work correctly, an error message is now emitted.
Root issue detected by Coverity scan, CID 185338
If the ptcp object creation fails, the socket is already open and
not freed upon error return. This scenario is extremely unlikely,
but we still should fix it.
Detected by Coverity scan, CID 158389
This is not a real problem because imdiag intentionally does multiple
tries to validate predicate validity. However, this is reported in
clang thread sanitizer and so we need to fix it.
small leak, can theoretically occur during rsyslog startup; will not
grow afterwards. Prime trigger would be out of process memory, which is
fatal in any case if it already occurs on startup.
Deteced by Coverity scan, CID 185322
We ensure that the previous line segment is always valid... actually this
was already done with existing code, but Coverity scan did not detect this.
Maybe we now get a control flow issue because we do what already happened
in this case...
CID 185423
This is a small static leak that happens during config reading. At
most one leak for each configured but invalid allowed sender.
Detectec by Coverity scan, CID 185378
When no variables exist and a variable with at least one variable in its path was used, then rsyslog was searching for that non existant variable
Rsyslog now aborts it when no variables exist.
closes https://github.com/rsyslog/rsyslog/issues/1920
keep a simple lock ... unlock scheme within the function. That is
easier to follow for both humans as well as static analyzers.
Also removes Coverity scan CID 185419
refactored the method so that it consistent in all functions and easier
to follow. Most importantly, now an as simple as possible locking paradigm
of lock ... unlock within the function. Hopefully easier to understand
both for humans and static code analyzers.
could theoretically happen if data structure was corrupted before
entering function. If so, would have lead to double unlock.
This is an experimental "solution" - if it works, we may consider
applying it to other places as well or working on a better one.
Detected by Coverity scan, CID 185469
Root of variable tree is accessed prior to locking access to it.
This introduces a race that may result in various kinds of
misadressing.
Found while reviewing code, no bug report exists.
If the config parameters were invalid, a misadressing could occur. If so,
this happens only during startup.
Also, a memory leak existed when the crypto provider errored out. This could
build up if it were used in frequently-changing dynafiles. This was
detected by Coverity scan, CID 185360.
Finally some light code simplification (free handling).
This removes what Coverity scan correctly identified as unnecessary.
However, it might have been there to prevent a clang static analyzer
false positive, so we check if this causes issues and merge only
if not. I keep this note in any case because it later might become
important info.
CID 185313
