On Wed, Mar 23, 2022 at 09:09:01PM +1000, Jonathan Matthew wrote:
> We noticed that the ntpd engine process was getting a bit big on some boxes
> that we'd accidentally cut off from the ntp servers (routing is hard).
> Reading through the code, I noticed the 'query' member of struct ntp_peer
> is never freed, which seems to account for the leak.
>
> If you have a server pool in ntpd.conf and it resolves, but ntpd is unable
> to talk to the servers, it will re-resolve periodically, freeing the old list
> of peers and creating new ones.
>
> To show how slow the leak is, here's the leak report from MALLOC_OPTIONS=D
> after running for about two hours with four servers from two pools.
>
> without diff:
>
> Leak report
> f sum # avg
> 0x0 9392 128 73
> 0x889878b920b 512 1 512
> 0x889878bc8e1 4096 4 1024
> 0x889878bd065 128 2 64
> 0x88bc91f0b4b 18280 1 18280
> 0x88bc926a9ed 65536 1 65536
>
>
> with diff:
>
> Leak report
> f sum # avg
> 0x0 6064 16 379
> 0xbee1253320b 512 1 512
> 0xbf0265f4b4b 18280 1 18280
> 0xbf02666e9ed 65536 1 65536
>
> ok?
OK bluhm@
> Index: ntp.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/ntpd/ntp.c,v
> retrieving revision 1.168
> diff -u -p -r1.168 ntp.c
> --- ntp.c 24 Oct 2021 21:24:19 -0000 1.168
> +++ ntp.c 23 Mar 2022 10:43:59 -0000
> @@ -686,6 +686,7 @@ void
> peer_remove(struct ntp_peer *p)
> {
> TAILQ_REMOVE(&conf->ntp_peers, p, entry);
> + free(p->query);
> free(p);
> peer_cnt--;
> }
