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
