[quagga-dev 1368] Re: Possible memory leak for self-originated opaque LSAs

gunnar.stigen at axxessit.no gunnar.stigen at axxessit.no
Tue Jul 27 11:44:08 BST 2004

Your proposal (to NOT null out the lsa ref. pointer) before "calling 
is just what I have tested out in my target system. No stability problems 
So the solution is simply to remove the statement oipi->lsa = NULL;

- Gunnar

Paul Jakma <paul at clubi.ie>
Sent by: quagga-dev-bounces at lists.quagga.net
09.07.2004 14:35

        To:     gunnar.stigen at axxessit.no
        cc:     quagga-dev at lists.quagga.net
        Subject:        [quagga-dev 1342] Re: Possible memory leak for self-originated opaque LSAs

On Wed, 23 Jun 2004 gunnar.stigen at axxessit.no wrote:

> Upon registration, the corresponding LSA is locked by this registration
> function in the statement
> oipi->lsa = ospf_lsa_lock (new);


>        oipi->lsa = NULL;
>        free_opaque_info_per_id ((void *) oipi);
> which I assume is the reverse action of what the registration function
> did.
> However, due to the statement  "oipi->lsa = NULL;"  the LSA is not
> unlocked within the function
> "free_opaque_info_per_id".


> Consequently, the LSA is not freed after the LSA maxage actions are 
> carried out. What I experience, is dangling" LSAs in memory with 
> lsa->lock = 1 and with no reference to the LSDB.
> Have I misunderstood something ?

Nope. Looks very much like it should not NULL out the lsa field. Can 
you confirm that fixes the problem and doesnt introduce stability 

> Regards Gunnar Stigen

Paul Jakma               paul at clubi.ie           paul at jakma.org Key ID: 
                 warning: do not ever send email to spam at dishone.st
"The sixties were good to you, weren't they?"
-- George Carlin
Quagga-dev mailing list
Quagga-dev at lists.quagga.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20040727/c58bb5c3/attachment-0001.html>

More information about the Quagga-dev mailing list