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 <[email protected]> on 
behalf of Matthias Andree via Dnsmasq-discuss 
<[email protected]>
Date: Thursday, January 29, 2026 at 7:52 PM
To: [email protected] 
<[email protected]>
Subject: Re: [Dnsmasq-discuss] Potential memory leak

From: Simon Kelley <[email protected]><mailto:[email protected]>
Date: Wednesday, January 28, 2026 at 11:17 AM
To: Niten Jaiswal <[email protected]><mailto:[email protected]>, 
[email protected]<mailto:[email protected]>
 
<[email protected]><mailto:[email protected]>
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)

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