| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
At least one case where this can occur is during thread shutdown, which
may be initiated by lower activity. In most cases, this is quite
unlikely to happen. However, if it does, data structures may be
corrupted which could lead to fatal failure and segfault. I detected
this via a testbench test, not a user report. But I assume that some
users may have had unreproducable aborts that were cause by this bug.
|
| | | |_|_|_|_|_|_|_|/
| | |/| | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=254
|
| | |\ \ \ \ \ \ \ \ \ |
|
| | | |\ \ \ \ \ \ \ \ \
| | | | |_|_|_|_|_|_|/ /
| | | |/| | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Conflicts:
runtime/datetime.c
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=271
|
| | | | |_|_|_|_|_|/ /
| | | |/| | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
This leak is tied to error conditions which lead to incorrect cleanup
of some data structures. [backport from v6, limited testing under v4]
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=270 (not yet confirmed!)
|
| | | |_|_|_|_|_|_|/
| | |/| | | | | | | |
|
| |\| | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Conflicts:
ChangeLog
runtime/nsd_gtls.c
tcpsrv.c
tests/Makefile.am
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
This leak is tied to error conditions which lead to incorrect cleanup
of some data structures.
Note: this is a backport from v6. In v5, we currently do not have
the toolchain to verify the original problem and that it is solved.
So this patch is preliminary and subject to change as work progresses.
|
| | | |_|_|_|/ / /
| | |/| | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This leak is tied to error conditions which lead to incorrect cleanup
of some data structures.
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This was a bug of the new implementation, never released code.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
this still has a couple of weaknesses, like no size limit, no expiration
of entries, suboptimal algorithms -- but it should perform better than
what we had previously. Implementation will be improved based on
feedback during the next couple of releases
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
did not return with proper return value
|
|\| | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Conflicts:
ChangeLog
plugins/imrelp/imrelp.c
|
| |\| | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
doc/rsyslog_conf_modules.html
plugins/imrelp/imrelp.c
|
| | |\| | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Conflicts:
runtime/queue.c
|
| | | | |_|_|_|/
| | | |/| | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
If the the multi-submit interface was used and a QUEUE_FULL condition
occured, the failed message was properly destructed. However, the
rest of the input batch, if it existed, was not processed. So this
lead to potential loss of messages and a memory leak. The potential
loss of messages was IMHO minor, because they would have been dropped
in most cases due to the queue remaining full, but very few lucky ones
from the batch may have made it. Anyhow, this has now been changed so
that the rest of the batch is properly tried to be enqueued and, if
not possible, destructed.
|
| |\| | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Conflicts:
tools/omfwd.c
|
| | | |_|_|/ /
| | |/| | | |
| | | | | | |
| | | | | | | |
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=258
|
| | |\| | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Leaks could occur under some circumstances if the file stream handler
errored out during the open call. Among others, this could cause very
big memory leaks if there were a problem with unreadable disk queue
files. In regard to the memory leak, this
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=256
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
now also properly works with privilege drop
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
as far as we know that new interface right now ;)
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| | |/ / / / /
| |/| | | | | |
|
| |\ \ \ \ \ \
| | | |/ / / /
| | |/| | / /
| | |_|_|/ /
| |/| | | | |
Conflicts:
tcpsrv.c
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Thanks to Peter Eisentraut for reporting and analysing this problem.
bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=221
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
re-doing the interface, global var "loadConf" now holds that data. Makes
things simpler with legacy handler, as well as new functionality.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
... plus some minor cleanup/code shuffle
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|