Mailing List Archive

Possible memory leak for self-originated opaque LSAs
With reference to the ospfd in the Quagga 0.96.5 release:

It seems to me that there is a possible bug in the opaque module:

In ospf_opaque.c, there is a function named "register_opaque_info_per_id".
This is called when an opaque client wants to originate a new opaque LSA.
Upon registration, the corresponding LSA is locked by this registration
function in the statement

oipi->lsa = ospf_lsa_lock (new);

If the client wants to flush the opaque LSA, the call sequence is as
follows:
=> ospf_apiserver_handle_delete_request (struct ospf_apiserver *apiserv,
struct msg *msg)
....
=> ospf_opaque_lsa_flush_schedule (old);
....
....
/* Disassociate internal control information with the given lsa.
*/
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 ?

Regards Gunnar Stigen













re are the free_opaque_info_per_id (void *val)
{

static struct opaque_info_per_id *
register_opaque_info_per_id (struct opaque_info_per_type *oipt,
struct ospf_lsa *new)
{
struct opaque_info_per_id *oipi;

if ((oipi = XCALLOC (MTYPE_OPAQUE_INFO_PER_ID,
sizeof (struct opaque_info_per_id))) == NULL)

{
zlog_warn ("register_opaque_info_per_id: XMALLOC: %s", strerror
(errno));
goto out;
}
oipi->opaque_id = GET_OPAQUE_ID (ntohl (new->data->id.s_addr));
oipi->t_opaque_lsa_self = NULL;
oipi->opqctl_type = oipt;
oipi->lsa = ospf_lsa_lock (new);

listnode_add (oipt->id_list, oipi);

out:
return oipi;
}

static void
free_opaque_info_per_id (void *val)
{
struct opaque_info_per_id *oipi = (struct opaque_info_per_id *) val;


OSPF_TIMER_OFF (oipi->t_opaque_lsa_self);
if (oipi->lsa != NULL)
ospf_lsa_unlock (oipi->lsa);
XFREE (MTYPE_OPAQUE_INFO_PER_ID, oipi);
return;
}
Re: Possible memory leak for self-originated opaque LSAs [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Gunnar,

| With reference to the ospfd in the Quagga 0.96.5 release:
|
| It seems to me that there is a possible bug in the opaque module:

I thought I should mention, that not long ago I had a discussion with
Paul, and he told me, that he thinks there is another bug in ospfapi:

[12:26] <paul> i dont know if it's anything, but i noticed a few direct
calls to ospf_lsa_free in ospf_apiserver.c
[12:26] <paul> amir: try changing those to ospf_lsa_unlock...

Now, as far as I understud, the reference counting works by
ospf_lsa_lock/unlock and one should never call ospf_lsa_free directly.
This would result in a strange ref-count problem I once traced but could
not pinpoint.

| [cut analysis]
| Have I misunderstood something ?

I think you got it quite right.

Regards
- - Amir
- --
Amir Guindehi, nospam.amir@datacore.ch
DataCore GmbH, Witikonerstrasse 289, 8053 Zurich, Switzerland

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-nr1 (Windows 2000)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA2pY+bycOjskSVCwRAnRjAKCPOxR5ASjTw1O9k9HiQAjrAowK1ACgsyI3
oHKvkXe2vpXQHfsCIHuy20s=
=g1zw
-----END PGP SIGNATURE-----
Re: Possible memory leak for self-originated opaque LSAs [ In reply to ]
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
Re: Possible memory leak for self-originated opaque LSAs [ In reply to ]
On Thu, 24 Jun 2004, Amir Guindehi wrote:

> Now, as far as I understud, the reference counting works by
> ospf_lsa_lock/unlock and one should never call ospf_lsa_free
> directly. This would result in a strange ref-count problem I once
> traced but could not pinpoint.

Have you had a chance to try that out btw?

Places where ospf_lsa_free() is called directly by apiserver:

ospf_apiserver_opaque_lsa_new - error case, it calls free on LSA it
has just new'd, this will instantly trigger the assert.

ospf_apiserver_lsa_refresher - this one _might_ be ok, calls
ospf_lsdb_lookup to retrieve the LSA (which does not change the
refcount) and calls ospf_lsa_free if ospf_lsa_install fails.

> I think you got it quite right.
>
> Regards
> - Amir

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
A Smith & Wesson beats four aces.
Re: Possible memory leak for self-originated opaque LSAs [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

| Have you had a chance to try that out btw?
|
| Places where ospf_lsa_free() is called directly by apiserver:
| [cut]

Sorry, nope. Did not came round to it...
The new Quagga ebuild and related problems are still on my todo. ;(

Regards
- - Amir
- --
Amir Guindehi, nospam.amir@datacore.ch
DataCore GmbH, Witikonerstrasse 289, 8053 Zurich, Switzerland

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-nr1 (Windows 2000)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA7uFmbycOjskSVCwRApiDAJ9A3XRPYrNvms81vJfPA3kemes0HQCgtLu6
oGgkFf9AT34Q7By28VZw348=
=+soH
-----END PGP SIGNATURE-----
Re: Possible memory leak for self-originated opaque LSAs [ In reply to ]
On Tue, 27 Jul 2004 gunnar.stigen@axxessit.no wrote:

> 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;

Fixed in CVS, thanks.

> - Gunnar

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Advertisements contain the only truths to be relied on in a newspaper.
-- Thomas Jefferson