--enable-rtinst is gone-away since a while, but there were still
some supporting code left. It required careful anaylsis what could
actually be removed. This is now done and the code fully cleaned
up.
As a positive side effect, we could eliminate mutex calls inside
the debug system. This means we are more likely to reproduce race
conditions in runs with debugging enabled.
closes https://github.com/rsyslog/rsyslog/issues/2211
These warnings are definitely overdone, but the clutter the build log
so we change it. It's kind of sad, as code cleanness is actually
reduced, but it doesn't help. The core issue is that we can suppress
the warning itself, but but the extra information lines to go with it.
as it looks, some compiler versions (e.g. gcc 7) seem to be rather
picky on the position where this attribute is applied. So this
commit moves them to the position where they are properly detected.
We also add missing attributes. Some are missing due to conditional
compilation what we did not detect in our regular development
environments. This now comes up as we have enabled the corresponding
warning globally, and so they now also show up on those platforms.
The --enable-rtinst configure switch and associated instrumentation
code dates back to the time pre-(valgrind, address sanitizer, ...).
It has not been actively used by rsyslog developers for years and is
inferior to the new debugging tools.
With this commit, we remove the --enable-rtinst option and do some
mild refactoring of the code itself. As it turned out, fully removing
the debug code requires a bit more of time, and we push this as a
follow-on activity. It's not as urgent as getting us to build
properly under all configure switches.
closes https://github.com/rsyslog/rsyslog/issues/2048
Remove the use sizeof(char) or sizeof(uchar) in calculations for memory
allocation or string length. There are no known platforms for which
sizeof(char) or sizeof(uchar) is not 1, and c99 has defined sizeof(char)
to be 1 (section 6.5.3.4 of c99).
Error: NULL_RETURNS (CWE-476):
rsyslog-7.4.10/runtime/debug.c:698: returned_null: Function "calloc(size_t, size_t)" returns null (checked 107 out of 123 times).
rsyslog-7.4.10/action.c:333: example_checked: Example 1: "calloc(1UL, 264UL)" has its value checked in "(pThis = (action_t *)calloc(1UL, 264UL)) == NULL".
rsyslog-7.4.10/grammar/rainerscript.c:932: example_checked: Example 2: "calloc(params->nParams, 24UL)" has its value checked in "(vals = calloc(params->nParams, 24UL)) == NULL".
rsyslog-7.4.10/outchannel.c:47: example_checked: Example 3: "calloc(1UL, 48UL)" has its value checked in "(pOch = calloc(1UL, 48UL)) == NULL".
rsyslog-7.4.10/parse.c:75: example_checked: Example 4: "calloc(1UL, 16UL)" has its value checked in "(pThis = (rsParsObj *)calloc(1UL, 16UL)) == NULL".
rsyslog-7.4.10/plugins/imfile/imfile.c:496: example_checked: Example 5: "calloc(1UL, 40UL)" has its value checked in "(pModConf = calloc(1UL, 40UL)) == NULL".
rsyslog-7.4.10/runtime/debug.c:698: var_assigned: Assigning: "pThrd" = null return value from "calloc(size_t, size_t)".
rsyslog-7.4.10/runtime/debug.c:699: dereference: Dereferencing a null pointer "pThrd".
- rsyslogd startup information is now properly conveyed back to init
when privileges are beging dropped
Actually, we have moved termination of the parent in front of the
priv drop. So it shall work now in all cases. See code comments in
commit for more details.
- If forking, the parent now waits for a maximum of 60 seconds for
termination by the child
- improved debugging support in forked (auto-backgrounding) mode
The rsyslog debug log file is now continued to be written across the
fork.
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>
I need to verify the concept used in a simpler environment, and this
means I probably need to freeze the (non-working) state here for
a couple of days.
