[syslog-ng] 3.3.0beta1 leaking memeory (Re: syslog-ng 3.3.0beta & ESX crashes)

[Balazs Scheidler]

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 at balabit.hu> writes:
> 
> > Hendrik Visage <hvjunk at 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 at 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 at 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