summaryrefslogtreecommitdiffstats
path: root/ChangeLog
Commit message (Collapse)AuthorAgeFilesLines
* bugfix: invalid storage type for config variablesRainer Gerhards2011-05-091-0/+1
|
* bugfix: stream driver mode was not correctly set on tcp ouput on big endian ↵Tomas Heinrich2011-05-091-0/+3
| | | | | | systems. Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
* bugfix: memory and file descriptor leak in stream processingRainer Gerhards2011-05-031-0/+6
| | | | | | | | 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
* bugfix: TCP connection invalidly aborted when messages needed to be discardedRainer Gerhards2011-05-021-0/+2
| | | | due to QUEUE_FULL or similar problem
* slightly more informative errmsg when TCP connection is abortedRainer Gerhards2011-05-021-0/+2
|
* bugfix: IPv6-address could not be specified in omrelpRainer Gerhards2011-04-141-0/+3
| | | | | this was due to improper parsing of ":" closes: http://bugzilla.adiscon.com/show_bug.cgi?id=250
* bugfix: omlibdbi did not use password from rsyslog.conRainer Gerhards2011-03-091-0/+2
| | | | closes: http://bugzilla.adiscon.com/show_bug.cgi?id=203
* bugfix: abort if imfile reads file line of more than 64KiBRainer Gerhards2011-02-101-0/+3
| | | | | Thanks to Peter Eisentraut for reporting and analysing this problem. bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=221
* imfile bugfix: potential duplication of log contentRainer Gerhards2011-01-101-0/+3
| | | | | | 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.
* bugfix: imfile potentially duplicates linesRainer Gerhards2010-12-171-0/+12
| | | | | | | | | | | | | | 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!
* some cleanup based on clang static analyzer resultsRainer Gerhards2010-12-161-0/+4
|
* Merge branch 'v3-stable' into v4-stableRainer Gerhards2010-12-161-0/+3
|\ | | | | | | | | Conflicts: ChangeLog
| * improved some code based on clang static analyzer resultsRainer Gerhards2010-12-161-0/+3
| |
* | Merge branch 'v4.4.2a' into v4-stableRainer Gerhards2010-11-251-5/+7
|\ \ | | | | | | | | | | | | | | | | | | | | | Conflicts: ChangeLog configure.ac plugins/imfile/imfile.c runtime/stream.c
| * | bugfix: a couple of problems that imfile had on some platformsRainer Gerhards2010-10-151-0/+2
| | | | | | | | | | | | namely Ubuntu (not their fault, but occured there)
| * | bugfix: imfile utilizes 32 bit to track offsetRainer Gerhards2010-10-151-0/+5
| | | | | | | | | | | | | | | Most importantly, this problem can not experienced on recent Fedora 64 bit OS (which has 64 bit long's!)
* | | final preparations for releasev4.6.5Rainer Gerhards2010-11-241-1/+1
| | |
* | | Merge branch 'v3-stable' into v4-stableRainer Gerhards2010-11-241-0/+10
|\ \ \ | | |/ | |/| | | | | | | | | | Conflicts: ChangeLog configure.ac
| * | bugfix(important): problem in TLS handling could cause rsyslog to loopv3.22.3Rainer Gerhards2010-11-241-0/+6
| | | | | | | | | | | | | | | | | | ... 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
* | | imfile: bugfixes in regard to large files (> 2GB)Rainer Gerhards2010-10-151-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | - 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!)
* | | preparing for 4.6.4v4.6.4Rainer Gerhards2010-08-051-1/+1
| | |
* | | Merge branch 'v3-stable' into v4-stableRainer Gerhards2010-08-051-1/+1
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: ChangeLog configure.ac doc/manual.html doc/professional_support.html
| * | preparing for 3.22.2v3.22.2Rainer Gerhards2010-08-051-1/+1
| | |
* | | Merge branch 'v3-stable' into v4-stableRainer Gerhards2010-08-051-0/+4
|\| | | | | | | | | | | | | | Conflicts: runtime/conf.c
| * | program name filter ! in the configuration cannot be resetKiss Gabor (Bitman)2010-08-051-0/+2
| | | | | | | | | | | | Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
* | | bugfix: zero-sized (empty) messages were processed by imtcpRainer Gerhards2010-07-281-0/+2
| | | | | | | | | | | | they are now dropped as they always should have been
* | | bumped version numberRainer Gerhards2010-07-071-0/+2
| | |
* | | preparing for 4.6.3v4.6.3Rainer Gerhards2010-07-071-1/+1
| | |
* | | bugfix: segfault on HUP when "HUPIsRestart" was set to "on"varmojfekoj2010-07-051-0/+2
| | | | | | | | | | | | Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
* | | some doc fixes; incorrect config samples could cause confusionRainer Gerhards2010-05-201-0/+2
| | | | | | | | | | | | thanks to Anthony Edwards for pointing the problems out
* | | added new configure option that permits to disable and enable an extended ↵Rainer Gerhards2010-04-121-0/+4
| | | | | | | | | | | | testbench
* | | bugfix: default for $OMFileFlushOnTXEnd was wrong ("off").Rainer Gerhards2010-04-071-0/+4
| | | | | | | | | | | | | | | | | | 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.
* | | improvded testbench: added test with truly random data received via syslog ↵Rainer Gerhards2010-04-011-0/+3
| | | | | | | | | | | | to test robustness
* | | temporary bugfix replaced by permanent one for...Rainer Gerhards2010-03-311-0/+4
| | | | | | | | | | | | | | | | | | ...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.
* | | bugfix: testbench failed when not executed in UTC+1 timezoneRainer Gerhards2010-03-291-0/+3
| | | | | | | | | | | | | | | accidently, the time zone information was kept inside some to-be-checked-for responses
* | | preparing for 4.6.2v4.6.2Rainer Gerhards2010-03-261-1/+1
| | |
* | | new feature: $OMFileAsyncWriting directive addedRainer Gerhards2010-03-251-0/+2
| | | | | | | | | | | | it permits to specifiy if asynchronous writing should be done or not
* | | bugfix(temporary): message-induced off-by-one error (potential segfault)Rainer Gerhards2010-03-251-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | bugfix: potential segfault in dynafile cacheRainer Gerhards2010-03-251-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | bugfix: race condition during directory creationRainer Gerhards2010-03-251-0/+5
| | | | | | | | | | | | | | | | | | | | | 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.
* | | bugfix: potential re-use of free()ed file stream object in omfileRainer Gerhards2010-03-231-0/+5
| | | | | | | | | | | | | | | | | | | | | 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)
* | | bugfix(minor): BSD_SO_COMPAT query function had some global vars not ↵Rainer Gerhards2010-03-221-0/+4
| | | | | | | | | | | | | | | | | | | | | properly initialized. However, in practice the loader initializes them with zero, the desired value, so there were no actual issue in almost all cases.
* | | bugfix: invalid buffer write in (file) stream classRainer Gerhards2010-03-191-0/+5
| | | | | | | | | | | | | | | | | | | | | 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)
* | | bugfix: potential hang condition during filestream closeRainer Gerhards2010-03-191-0/+3
| | | | | | | | | | | | | | | predicate was not properly checked when waiting for the background file writer
* | | bugfix: improper synchronization when "$OMFileFlushOnTXEnd on" was usedRainer Gerhards2010-03-191-0/+3
| | | | | | | | | | | | | | | Internal data structures were not properly protected due to missing mutex calls.
* | | new feature: "." action type added to support writing files to relative pathesRainer Gerhards2010-03-171-0/+2
| | | | | | | | | | | | (this is primarily meant as a debug aid)
* | | bugfix: recent patch to fix small memory leak could cause invalid free.Rainer Gerhards2010-03-161-0/+2
| | | | | | | | | | | | This could only happen during config file parsing.
* | | bugfix(minor): handling of extremely large strings in dbgprintf() fixedRainer Gerhards2010-03-151-0/+4
| | | | | | | | | | | | | | | | | | 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.
* | | bugfixes and testbench improvementRainer Gerhards2010-03-101-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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.
* | | bugfix: potential problem (loop, abort) when file write error occuredRainer Gerhards2010-03-091-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit (git 2.34.1) at 2024-05-27 02:14:11 +0000