[Dnsmasq-discuss] Potential memory leak

Matthias Andree matthias.andree at gmx.de
Fri Jan 30 00:42:00 UTC 2026


> *From: *Simon Kelley <simon at thekelleys.org.uk>
> *Date: *Wednesday, January 28, 2026 at 11:17 AM
> *To: *Niten Jaiswal <niten at jaiswal.net>, 
> dnsmasq-discuss at lists.thekelleys.org.uk 
> <dnsmasq-discuss at lists.thekelleys.org.uk>
> *Subject: *Re: [Dnsmasq-discuss] Potential memory leak
>
> I've just pushed some changes to the git repo, whichinclude a new option
> called --log-malloc. If you can run that code, and enable log-malloc and
> save the log file, that might be interesting. There will be a reasonable
> amount of activity after startup, but once the various tables reach
> equilibrium size, it should be pretty quiet. If it's not, or there are
> some very large allocations, that could give us a clue.
>
> This has been quite useful: I found a few non-optimal behaviours, which
> I've fixed, but nothing that actually leaks memory.
>

Am 28.01.26 um 20:10 schrieb Niten Jaiswal via Dnsmasq-discuss:
> HI Simon,
> I’m not sure if I can run your version on opnsense.  The opnsense team 
> gave me a patch to install that will remove the quiet options and have 
> shown me how to enable the logging you requested.  I will turn 
> everything on later today.
>

Niten,

that's not useful. Please compile a debug version of dnsmasq from ports; 
I have just updated the FreeBSD port dns/dnsmasq-devel to v2.93test2, 
and then either add the log-malloc option, or alternatively, install 
valgrind (pkg install valgrind) and run dnsmasq under valgrind (slower) 
instead. Check how you normally call it, shut it down, then add the 
valgrind + options before dnsmasq, and a -d at the end, and watch.

In order to debug properly, please build dnsmasq from ports, update your 
ports checkout, or download and unpack the port:
https://gitlab.com/FreeBSD/freebsd-ports/-/archive/main/freebsd-ports-main.tar.bz2?ref_type=heads&path=dns/dnsmasq-devel

then cd to the directory where you unpacked it and "make 
WITH_DEBUG=yes", if that succeeds, "make WITH_DEBUG=yes reinstall".

Then, restart dnsmasq in with valgrind:

valgrind --trace-children=yes --leak-check=full /usr/local/sbin/dnsmasq 
-x /var/run/dnsmasq.pid -C /usr/local/etc/dnsmasq.conf -d

A leak report of a synthetic leak program that deliberately leaks memory 
with valgrind looks like this:

> $ valgrind --trace-children=yes --leak-check=full ~/leak
> ==20388== Memcheck, a memory error detector
> ==20388== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
> ==20388== Using Valgrind-3.26.0 and LibVEX; rerun with -h for 
> copyright info
> ==20388== Command: /home/mandree/leak
> ==20388==
> line 5: x = 0x5600040
> line 7: x = 0x56010e0
> ==20388==
> ==20388== HEAP SUMMARY:
> ==20388==     in use at exit: 4,113 bytes in 2 blocks
> ==20388==   total heap usage: 3 allocs, 1 frees, 4,136 bytes allocated
> ==20388==
> ==20388== 17 bytes in 1 blocks are definitely lost in loss record 1 of 2
> ==20388==    at 0x484D224: malloc (vg_replace_malloc.c:451)
> ==20388==    by 0x20168F: main (leak.c:4)
> ==20388==
> ==20388== LEAK SUMMARY:
> ==20388==    definitely lost: 17 bytes in 1 blocks
> ==20388==    indirectly lost: 0 bytes in 0 blocks
> ==20388==      possibly lost: 0 bytes in 0 blocks
> ==20388==    still reachable: 0 bytes in 0 blocks
> ==20388==         suppressed: 4,096 bytes in 1 blocks
> ==20388==
> ==20388== For lists of detected and suppressed errors, rerun with: -s
> ==20388== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20260130/4c21417a/attachment.htm>


More information about the Dnsmasq-discuss mailing list