| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Max size is now 32K.
|
| |
|
|
|
|
|
|
|
| |
This resulted in wrong values. The most prominent victim was the
directory creation mode, which was set to zero in some cases. For
details, see related blog post:
http://blog.gerhards.net/2009/10/another-note-on-hard-to-find-bugs.html
This replaces the improper bugfix from two commits ago with a proper one.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
one-time write to the mode, then all works. However, if no such write
is done, the variable always remains zero. I have used the memory
debugger as well as shuffled the code around and used guard variables
nothing changed. The problem always moved with the changes I did. So
I now consider the one-time write a usable work-around, because it
definitely fixes the issue even though it does not explain why it
happens.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
we needed to release ALL resources (including file handles!) only
after the the async writer thread has terminated (else it may access
them). In this case, we had a file handle leak, because the handle was
sometimes only opened in the async writer, but the close was attempted
before the writer even started (in some cases).
|
| |
|
|
|
|
| |
...after we seem to have identified the root cause of the segfault.
I leave them commented out so that we can re-activate it if need
arises (aka "get some practice drill first").
|
| |
|
|
|
|
|
|
|
|
| |
Most severely affected omfile. The problem was that some buffers were
freed before the asynchronous writer thread was shut down. So the
writer thread accessed invalid data, which may even already be
overwritten. Symptoms (with omfile) were segfaults, grabled data
and files with random names placed around the file system (most
prominently into the root directory). Special thanks to Aaron for
helping to track this down.
|
| |
|
|
|
| |
if the buffer was too small, we would see more API calls, but no
failure, so this is no fix!
|
| |
|
|
|
|
| |
Problems could lead to abort and/or memory leak. The module is now hardened in a very
conservative way, which is sub-optimal from a performance point of view. This should
be improved if it has proven reliable in practice.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
this could lead to loss of the repeated message content. As a side-
effect, it could probably also be possible that some segfault occurs
(quite unlikely). The root cause was that some counters introduced
during the malloc optimizations were not properly duplicated in
MsgDup(). Note that repeated message processing is not enabled
by default.
|
| | |
|
| |\ |
|
| | |\
| | |
| | |
| | |
| | | |
Conflicts:
doc/rsyslog_conf.html
|
| | | |
| | |
| | |
| | | |
in doc set (require TLS drivers)
|
| |\| |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A comparison was done between the current and the former source address.
However, this was done on the full sockaddr_storage structure and not
on the host address only. This has now been changed for IPv4 and IPv6.
The end result of this bug could be a higher UDP message loss rate than
necessary (note that UDP message loss can not totally be avoided due
to the UDP spec)
|
| | | | |
|
| |\| |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
runtime/msg.c
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Note that the orginal (higher version) patch states this happens only
when debugging mode is turned on. That statement is wrong: if debug
mode is turned off, the message is not being emitted, but the division
by zero in the actual parameters still happens.
|
| | | |
| | |
| | |
| | |
| | | |
This causes grief with all receivers.
Bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=147
|
| | | |
| | |
| | |
| | | |
(thanks to Michael Biebl for his help!)
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This resulted in build errors if no Java was present on the build system,
even though none of the selected option actually required Java.
(I forgot to backport a similar fix to newer releases).
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- control character DEL was not properly escaped
- NUL and LF characters were not properly stripped if no control
character replacement was to be done
- NUL characters in the message body were silently dropped (this was
a regeression introduced by some of the recent optimizations)
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
... resulting in some message properties be populated with strings from
previous messages. This was caused by an improper predicate check.
|
| | | | |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
... thus causing them to be treated as TAG (this was a regression
introduced from the "rfc3164 strict" change in 4.5.0).
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In async write mode, we use modular arithmetic to index the output
buffer array. However, the counter variables accidently were signed,
thus resulting in negative indizes after integer overflow. That in turn
could lead to segfaults, but was depending on the memory layout of
the instance in question (which in turn depended on a number of
variables, like compile settings but also configuration). The counters
are now unsigned (as they always should have been) and so the dangling
mis-indexing does no longer happen. This bug potentially affected all
installations, even if only some may actually have seen a segfault.
|
| | | | |
| | | |
| | | |
| | | | |
permits to specify how many TCP servers shall be possible (default is 20).
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Some devices seem to create them and I do not see any harm in supporting that.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This is for another prctl() call, not present in the beta version (looks like it
would make sense to stick these into a utility function)
|
| | |\ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
v4-beta was so far unreleased, so it was a bug only here
|
| | |\ \ \ \ |
|
| | | | | | | |
|
| | |\ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
...after sending n messages (actually, it re-opens the connection, the
name is used because this is a concept very similiar to
$ActionUDPRebindInterval). New config directive $ActionSendTCPRebindInterval
added for the purpose. By default, rebinding is disabled. This is considered#
useful for load balancers.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
added tcp output rebinding option.
needs some more testing and doc
|
| | |\ \ \ \ \ \ |
|
