From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gisle Vanem <gisle.vanem@gmail.com>
To: location@lists.ipfire.org
Subject: Mem-leaks in 'test-as.c'
Date: Sat, 24 Oct 2020 10:12:11 +0200
Message-ID: <8624037f-834c-4908-3268-543112d35051@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6468944924683442321=="
List-Id: <location.lists.ipfire.org>

--===============6468944924683442321==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Michael Tremer wrote:

> First thing to know is that we use reference counting for all objects.
> So every pointer that refers to an object has to decrement
> the counter when it no longer needs it. The object will be automatically
> cleaned up after nothing needs it any more.

In 'test-as.c', I get a huge amount of leaks in MSVC
debug-mode. Since 'loc_database_enumerator_unref()' just
unreferences itself and not the 'as' (working as designed?)
IMHO it should be:

--- a/test-as.c 2020-10-19 17:35:01
+++ b/test-as.c 2020-10-24 10:01:57
@@ -111,12 +111,17 @@

         while (as) {
                 printf("Found AS%d: %s\n", loc_as_get_number(as), loc_as_get=
_name(as));

-               err =3D loc_database_enumerator_next_as(enumerator, &as);
+               struct loc_as* as_next;
+
+               err =3D loc_database_enumerator_next_as(enumerator, &as_next);
                 if (err) {
                         fprintf(stderr, "Could not enumerate next AS\n");
                         exit(EXIT_FAILURE);
                 }
+               loc_as_unref(as);
+               as =3D as_next;
         }

         loc_database_enumerator_unref(enumerator);

With that patch, no reported leaks.

Could be leaks in 'libloc' itself too; haven't checked yet.

--=20
--gv


--===============6468944924683442321==--