| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|\
| |
| |
| |
| | |
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]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| | |
systems.
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
due to QUEUE_FULL or similar problem
|
| | |
|
| |
| |
| |
| |
| | |
this was due to improper parsing of ":"
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=250
|
| |
| |
| |
| | |
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=203
|
| |
| |
| |
| |
| | |
Thanks to Peter Eisentraut for reporting and analysing this problem.
bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=221
|
| |
| |
| |
| |
| |
| | |
Under some circumstances an invalid truncation was detected. This
code has now been removed, a file change (and thus resent) is only
detected if the inode number changes.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This can happen when 0 bytes are read from the input file, and some
writer appends data to the file BEFORE we check if a rollover happens.
The check for rollover uses the inode and size as a criterion. So far,
we checked for equality of sizes, which is not given in this scenario,
but that does not indicate a rollover. From the source code comments:
Note that when we check the size, we MUST NOT check for equality.
The reason is that the file may have been written right after we
did try to read (so the file size has increased). That is NOT in
indicator of a rollover (this is an actual bug scenario we
experienced). So we need to check if the new size is smaller than
what we already have seen!
|
| | |
|
|\|
| |
| |
| |
| | |
Conflicts:
ChangeLog
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
plugins/imfile/imfile.c
runtime/stream.c
|
| | |
| | |
| | |
| | | |
namely Ubuntu (not their fault, but occured there)
|
| | |
| | |
| | |
| | |
| | | |
Most importantly, this problem can not experienced on recent Fedora
64 bit OS (which has 64 bit long's!)
|
| | | |
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
|
| | |
| | |
| | |
| | |
| | |
| | | |
... in a tight loop, effectively disabling functionality and bearing the
risk of unresponsiveness of the whole system.
Bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=194
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- bugfix: a couple of problems that imfile had on some platforms, namely
Ubuntu (not their fault, but occured there)
- bugfix: imfile utilizes 32 bit to track offset. Most importantly,
this problem can not experienced on Fedora 64 bit OS (which has
64 bit long's!)
|
| | | |
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|