[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