Mailing List Archive

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

- Gunnar





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


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


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

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

Ok.

> 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".

Ah.

> 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
problems?

> Regards Gunnar Stigen

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID:
64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
"The sixties were good to you, weren't they?"
-- George Carlin
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev