| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
|
|\| | |
|
| | | |
|
|\| |
| | |
| | |
| | |
| | | |
Conflicts:
action.c
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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:
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)
|
| | |
| | |
| | |
| | |
| | | |
This causes grief with all receivers.
Bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=147
|
| | |\
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
tests/Makefile.am
|
|\| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- 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.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
... resulting in some message properties be populated with strings from
previous messages. This was caused by an improper predicate check.
|
|\| | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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 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).
|
|\| | | |
|
| | | |
| | | |
| | | |
| | | | |
Some devices seem to create them and I do not see any harm in supporting that.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
... but an alternate approach via pthread_kill. This is somewhat safer as we
do not need to think about the cancel-safeness of all libraries we use.
However, not all inputs can easily supported, so this now is a feature
that can be requested by the input module (the most important ones
request it).
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
the new handling will hopefully spare a few cycles, as function calls
(and most importantly parameter generation!) or now only done when
debug messages are actually active.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
code review brought up some few places where we may have run into a race.
They have most probably been introduced during the recent set of changes. But
I do not look at older versions because of the changed architecture, one can
not simply backport this patch.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This did NOT leak based on message volume. Also, did some cleanup during
the commit.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
... greater performance and was able to remove a potential troublespot
in a cancel cleanup handler.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
...if not running in direct mode. Previous versions could run without
any active workers. This simplifies the code at a very small expense.
See v5 compatibility note document for more in-depth discussion.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
... as well as some cleanup
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
... by utilizing that we need to modify a state variable only in
a sequential way during shutdown.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
... could even remove one mutex by using a better algorithm. I think I also
spotted some situation in which a hang could have happened. As I can't fix it
in v4 and less without moving to the new engine, I make no effort in testing
this out. Hangs occur during shutdown, only (if at all). The code changes
should also result in some mild performance improvement. Some bug potential,
but overall the bug potential should have been greatly reduced.
|
| | | |
| | | |
| | | |
| | | | |
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:
tests/nettester.c
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
based on now working with detached threads. This is probably the biggest
patch in this series and with large bug potential.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
... only those things that were obvious (and puzzled people looking at
the code without konwing the subtle issues of HUP ;)).
|