Hi, Thanks for the info, I'll try to look at this today. On Fri, 2011-07-22 at 14:04 +0200, Gergely Nagy wrote:
Gergely Nagy <algernon@balabit.hu> writes:
Hendrik Visage <hvjunk@gmail.com> writes:
I've mailed Gergely the Valgrind output to analyze 3.3.0beta1 memory leak(s), so if anybody else are interested in it, please contact me for them.
I had a little time to look into the memory leak issue, and I can confirm: the leak happens all the time with latest git.
After a bit of bisecting, this is what i found to be the cause of the massive leak:
b8cc9fe3bb41d862918d9e39b0ded812dd756ef5 is the first bad commit commit b8cc9fe3bb41d862918d9e39b0ded812dd756ef5 Author: Balazs Scheidler <bazsi@balabit.hu> Date: Thu Jul 14 12:26:01 2011 +0200
delegate flow-control early-ack decision to destination drivers
Sources always expect an acknowledgement for each message they produce. This acknowledgement is usually generated when all the destinations have finished their processing of the given message, unless flow-control is disabled.
Earlier the LogMultiplexer object was responsible for ACKing in the name of destinations where flow-control was not desired. This patch changes that and delegates the early-ack (or break-ack) decision to destination drivers, based on the information stored in the LogPathOptions structure, where the user-requested mode of operation is stored.
This patch splits the "flow_control" member of the LogPathOptions structure into two:
- ack_needed: specifies whether the source still expects an ACK on the current path. - flow_control_requested: specifies whether the user has enabled flow control on the current path.
Based on these, the destination driver is able to make a decision when to perform the ACK:
- log_msg_break_ack(): is a new function call that can be used to generate the ACK and prepare for _sending_ the same message for further processing. - log_msg_ack(): is the good-old ack generation function that can be used when the processing is finally finished, and no processing is to be done.
Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
:040000 040000 a26bae67903b4109d7b38fbc7c5189c16cc34537 498a1f804d5f3cc578d4fc0dd3833e9b2088a4f8 M lib :040000 040000 7ee20d0fad233792bc68b1db27e3377a22a21499 14bfecc8d10a9a4a36fbe4f38d68b2cef2f6aa63 M modules :040000 040000 eb95b6f26303ac0e879321b6f4366ff8dae66f69 19c30ee65e21c7ef10148630546658e28ac0f5b9 M tests
I'm looking into what exactly this patch does, and where the LogMessage freeing should be added.
Reverting the above patch from git head does, indeed, make the leak go away.
-- Bazsi