[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] [PATCH] Fix setup_service memory leak in util/se
From: |
jah |
Subject: |
Re: [GNUnet-developers] [PATCH] Fix setup_service memory leak in util/service.c |
Date: |
Thu, 8 Jun 2017 19:40:14 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0 |
On 07/06/17 08:10, LRN wrote:
> For that matter, it should be possible to GNUNET_free(addrs[i])
> unconditionally, before the socket opening check (GCC probably optimizes like
> that anyway, but why not help it?).
Thank you LRN, yes it is possible and here's the improved patch:-
---
src/util/service.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/util/service.c b/src/util/service.c
index d195452c9..fcdf45a51 100644
--- a/src/util/service.c
+++ b/src/util/service.c
@@ -1283,15 +1283,14 @@ setup_service (struct GNUNET_SERVICE_Handle *sh)
slc->sh = sh;
slc->listen_socket = open_listen_socket (addrs[i],
addrlens[i]);
+ GNUNET_free (addrs[i]);
if (NULL == slc->listen_socket)
{
GNUNET_log_strerror (GNUNET_ERROR_TYPE_ERROR,
"bind");
- GNUNET_free (addrs[i]);
GNUNET_free (slc);
continue;
}
- GNUNET_free (addrs[i]);
GNUNET_CONTAINER_DLL_insert (sh->slc_head,
sh->slc_tail,
slc);
--
2.13.1
> More worrying, to me, is the fact that addrs array is "struct sockaddr ***",
> where each struct is malloced individually and put into an array that is also
> malloced itself. Maximum possible sockaddr size is known, so why isn't it just
> a "struct sockaddr **"?
I'm afraid it's a bit beyond me to answer this, or to correct it.
jah