| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
by implementing some code that was missing so far ;) as well as
finding some real bugs. I also did some general cleanup, removing
debug strings and such. This code should be fairly OK to use, except
when "exec only when previous action was suspended" is used -- this is
NOT yet re-implemented in the tuned engine.
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
runtime/msg.h
runtime/rsyslog.h
runtime/stream.c
|
| |
| |
| |
| | |
including refctoring for a more simple solution
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
plugins/imudp/imudp.c
runtime/stream.h
tests/Makefile.am
tests/diag.sh
tools/omfile.c
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
runtime/debug.c
runtime/stream.c
tests/Makefile.am
tests/diskqueue.sh
tests/nettester.c
tools/omfile.c
|
| | |
| | |
| | |
| | |
| | |
| | | |
The old code looks a bit "strange", though not necessarily incorrect.
The new code looks correct and is probably less irritating during bug
hunting.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The previous fix fixed an issue with on/off bying used in the exact wrong
semantic. It corrected the situation, but failed to fix one spot where the
wrong semantics were used. This is done with this commit.
Note that this is NOT a bug seen in any released version.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | |\ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
disk queue mode did no longer work correctly. A side-effect of
this commit here is slightly cleaned-up (and more elegant) code
for circular files.
|
| | |/
| | |
| | |
| | |
| | |
| | | |
note that a buffer size calculation was done wrong, but this was cosmetic
because our buffers currently all use byte size, so even though the
formula was wrong, the result was correct.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- 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.
|
|/ /
| |
| |
| | |
issues
|
|\|
| |
| |
| |
| | |
Conflicts:
ChangeLog
|
| |
| |
| |
| | |
Thanks to Michael Biebl for reporting this bug.
|
|\| |
|
| |
| |
| |
| | |
this was a regression from the omfile rewrite in 4.5.0
|
| |
| |
| |
| |
| |
| |
| |
| | |
support for enhancing probability of memory addressing failure by
using non-NULL default value for malloced memory (optional, only if
requested by configure option). This helps to track down some
otherwise undetected issues within the testbench and is expected
to be very useful in the future.
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\| |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I found out that the previous segfault fix did not correct the root
cause of the problem. Thus, I can re-instantiate the more performance-
optimal logic. In the next step, I'll merge in the real fix, so do NOT
use this commit as code you actually run!
|
| | | |
|
|\| | |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
I have undone a very small optimization with using pre-malloced memory,
which seems to have some issues. Now I am doing mallocs and at least in
test environment this seems to solve the issue. The code now needs more
review. If it runs flawlessly for some time, I may try to re-enable to
pre-malloc, but not necessarily: its performance benefit is very mild
(aka: I don't think it justifies introducing bigger complexities).
|
| |
| |
| |
| | |
reducing the number of thread cancellation state changes
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
runtime/wti.c
runtime/wtp.c
|
| |
| |
| |
| |
| | |
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)
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
runtime/debug.h
runtime/stream.c
|
| |
| |
| |
| |
| |
| | |
for the stream class and thus finally activating omfile's timeout
capability in a useful way without polling and too-high performance
overhead.
|
| | |
|
| | |
|
| | |
|
| | |
|