| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
doc/professional_support.html
|
| | |
|
|\|
| |
| |
| |
| | |
Conflicts:
runtime/conf.c
|
| |
| |
| |
| | |
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
| |
| |
| |
| | |
they are now dropped as they always should have been
|
| | |
|
| | |
|
| |
| |
| |
| | |
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
| |
| |
| |
| | |
thanks to Anthony Edwards for pointing the problems out
|
| |
| |
| |
| | |
testbench
|
| |
| |
| |
| |
| |
| | |
This, in default mode, caused buffered writing to be used, what
means that it looked like no output were written or partial
lines. Thanks to Michael Biebl for pointing out this bug.
|
| |
| |
| |
| | |
to test robustness
|
| |
| |
| |
| |
| |
| | |
...message-induced off-by-one error (potential segfault) (see 4.6.2)
The analysis has been completed and a better fix been crafted and
integrated.
|
| |
| |
| |
| |
| | |
accidently, the time zone information was kept inside some
to-be-checked-for responses
|
| | |
|
| |
| |
| |
| | |
it permits to specifiy if asynchronous writing should be done or not
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some types of malformed messages could trigger an off-by-one error
(for example, \0 or \n as the last character, and generally control
character escaption is questionable). This is due to not strictly
following a the \0 or string counted string paradigm (during the last
optimization on the cstring class). As a temporary fix, we have
introduced a proper recalculation of the size. However, a final
patch is expected in the future. See bug tracker for further details
and when the final patch will be available:
http://bugzilla.adiscon.com/show_bug.cgi?id=184
Note that the current patch is considered sufficient to solve the
situation, but it requires a bit more runtime than desirable.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This bug was triggered by an open failure. The the cache was full and
a new entry needed to be placed inside it, a victim for eviction was
selected. That victim was freed, then the open of the new file tried. If
the open failed, the victim entry was still freed, and the function
exited. However, on next invocation and cache search, the victim entry
was used as if it were populated, most probably resulting in a segfault.
|
| |
| |
| |
| |
| |
| |
| | |
If multiple files try to create a directory at (almost) the same time,
some of them may fail. This is a data race and also exists with other
processes that may create the same directory. We do now check for this
condition and gracefully handle it.
|
| |
| |
| |
| |
| |
| |
| | |
when dynaCache is enabled, the cache is full, a new entry needs to
be allocated, thus the LRU discarded, then a new entry is opend and that
fails. In that case, it looks like the discarded stream may be reused
improperly (based on code analysis, test case and confirmation pending)
|
| |
| |
| |
| |
| |
| |
| | |
properly initialized.
However, in practice the loader initializes them with zero, the
desired value, so there were no actual issue in almost all cases.
|
| |
| |
| |
| |
| |
| |
| | |
currently being accessed buffer could be overwritten with new data.
While this probably did not cause access violations, it could case loss
and/or duplication of some data (definitely a race with no deterministic
outcome)
|
| |
| |
| |
| |
| | |
predicate was not properly checked when waiting for the background file
writer
|
| |
| |
| |
| |
| | |
Internal data structures were not properly protected due to missing
mutex calls.
|
| |
| |
| |
| | |
(this is primarily meant as a debug aid)
|
| |
| |
| |
| | |
This could only happen during config file parsing.
|
| |
| |
| |
| |
| |
| | |
Previously, it could lead to garbagge output and, in extreme cases, also
to segfaults. Note: this was a problem only when debug output was
actually enabled, so it caused no problem in production use.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- improved testbench
- bugfix: potential data loss during file stream shutdown
- bugfix: potential problems during file stream shutdown
The shutdown/close sequence was not clean, what potentially (but
unlikely) could lead to some issues. We have not been able to describe
any fatal cases, but there was some bug potential. Sequence has now
been straighted out.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a write error occured in stream.c, variable iWritten had the error
code but this was handled as if it were the actual number of bytes
written. That was used in pointer arithmetic later on, and thus could
lead to all sorts of problems. However, this could only happen if the
error was EINTR or the file in question was a tty. All other cases were
handled properly. Now, iWritten is reset to zero in such cases, resulting
in proper retries.
|
| | |
|
| |
| |
| |
| |
| | |
primarily to ease migration from syslog-ng. See property replacer doc for
details. [backport from 5.5.3 because urgently needed by some]
|
| | |
|
| |
| |
| |
| | |
including proper credits to Mandriva team.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- bugfix: potential segfault in omfile when a dynafile open failed
In that case, a partial cache entry was written, and some internal
pointers (iCurrElt) not correctly updated. In the next iteration, that
could lead to a segfault, especially if iCurrElt then points to the
then-partial record. Not very likely, but could happen in practice.
- bugfix (theoretical): potential segfault in omfile under low memory
condition. This is only a theoretical bug, because it would only
happen when strdup() fails to allocate memory - which is highly
unlikely and will probably lead to all other sorts of errors.
|
| | |
|
|\|
| |
| |
| |
| | |
Conflicts:
runtime/ctok.c
|
| |
| |
| |
| |
| | |
...and thus could not be used.
but tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=119
|
| |
| |
| |
| |
| | |
bugtracker: http://bugzilla.adiscon.com/show_bug.cgi?id=181
Thanks to Christiano for reporting.
|
| |
| |
| |
| | |
while the rest of the entry correctly said it was stable.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- improved testbench to contain samples for totally malformed messages
which miss parts of the message content
- bugfix: some malformed messages could lead to a missing LF inside files
or some other missing parts of the template content.
- bugfix: if a message ended immediately with a hostname, the hostname
was mistakenly interpreted as TAG, and localhost be used as hostname
|
| |
| |
| |
| |
| |
| |
| | |
[backported from v5 commit 98d1ed504ec001728955a5bcd7916f64cd85f39f]
This actually was a "recent" regression, but I did not realize that it
was introduced by the performance optimization in v4-devel. Shame on
me for having two devel versions at the same time...
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- bugfix: property replacer returned invalid parameters under some (unusual)
conditions. In extreme cases, this could lead to garbled logs and/or
a system failure.
- bugfix: invalid length returned (often) when using regular expressions
inside the property replacer
- bugfix: submatch regex in property replacer did not honor "return 0 on
no match" config case
|
| |
| |
| |
| | |
converted to html, linked, etc...
|
| |
| |
| |
| | |
Thanks to Ryan Lynch for reporting this.
|
|\ \ |
|
| | |
| | |
| | |
| | | |
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
| | |
| | |
| | |
| | |
| | |
| | | |
correct value on FreeBSD.
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
|\| |
| | |
| | |
| | |
| | | |
Conflicts:
runtime/queue.c
|