Hi Simon,
I’m going to ask the OPNSense team and get back to you.

Niten

From: Dnsmasq-discuss <[email protected]> on 
behalf of Simon Kelley <[email protected]>
Date: Friday, January 30, 2026 at 11:59 AM
To: [email protected] 
<[email protected]>
Subject: Re: [Dnsmasq-discuss] Potential memory leak

I just sent SIGHUP twice in succession to the dnsmasq process in my
OpenWRT router, with the new malloc-logging feature enabled.

HUP frees a load of configuration and the re-reads it and I correlated
all the memory freed by the second HUP with what was allocated in the
first HUP.

It's perfect. Every block is freed.


This is a fairly old installation, so old libraries, etc, but the very
latest dnsmasq code.

The configuration it's re-reading is pretty small.

I then tried your technique of hitting dnsmasq hard with many HUPs.

I had to go up to half a million to see much effect, but I guess most of
those were dropped since they will have arrived before the previous one
was cleared.

In any case I could see a reproducible rise of a few percent in the VSZ
of the process each time.

What's clear is that the configuration is stored in a _lot_ of small
allocations, so re-reading a substantial configuration  will free a lot
of small blocks and then malloc a lot of small blocks.

A quick Google produces some complaints about the fragmentation
performance of musl, which may be significant.

Is your installation using musl as the C library, and is it possible to
build dnsmasq against, say glibc to test?

Nearly all of the memory management on dnsmasq that gets hit by
answering DNS or DHCP requests avoid hammering the malloc system by
building pools of free data structures that get re-cycled as needed.
Once the pools have grown to equilibrium size, even a very busy server
hardly uses the heap. I guess the configuration code to use the same
policy, but it's a big re-write, and re-reading configuration on a
sub-second timescale is an unlikely use-case.




Cheers,

Simon.





On 30.01.2026 01:59, Y.Y. wrote:
> *Hi Simon,*
>
> I think Your suspicion about the configuration re-reading logic is spot
> on. I have documented the reproduction and some analysis here: https://
> github.com/openwrt/openwrt/issues/21729#issuecomment-3815442601
> <https://github.com/openwrt/openwrt/issues/21729#issuecomment-3815442601>
>
> To assist with the debugging, I can provide an OpenWrt *Linux x86_64 VM
> image* that consistently reproduces this memory leak. Please let me know
> if this would be helpful for your investigation.
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> [email protected]
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss