[Dnsmasq-discuss] Potential memory leak

[Niten Jaiswal]

Hi Matthias,
I’m working with the Opnsense team to see if they can offer the development build as an option to install.

From: Dnsmasq-discuss <dnsmasq-discuss-bounces at lists.thekelleys.org.uk> on behalf of Matthias Andree via Dnsmasq-discuss <dnsmasq-discuss at lists.thekelleys.org.uk>
Date: Thursday, January 29, 2026 at 7:52 PM
To: dnsmasq-discuss at lists.thekelleys.org.uk <dnsmasq-discuss at lists.thekelleys.org.uk>
Subject: Re: [Dnsmasq-discuss] Potential memory leak

From: Simon Kelley <simon at thekelleys.org.uk><mailto:simon at thekelleys.org.uk>
Date: Wednesday, January 28, 2026 at 11:17 AM
To: Niten Jaiswal <niten at jaiswal.net><mailto:niten at jaiswal.net>, dnsmasq-discuss at lists.thekelleys.org.uk<mailto:dnsmasq-discuss at lists.thekelleys.org.uk> <dnsmasq-discuss at lists.thekelleys.org.uk><mailto: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/20260131/c00a2dd7/attachment-0001.htm>