Am 30.01.26 um 17:33 schrieb Simon Kelley:
I just sent SIGHUP twice in succession to the dnsmasq process in my OpenWRT router, with the new malloc-logging feature enabled.I've built dnsmasq v2.93test2 on Fedora Linux 43 (amd64 aka x86_64) with address and undefined behavior sanitizers in GCC and with HAVE_DNSSEC, and I am providing three patches (should suit git-am) to fixHUP frees a load of configuration and the re-reads it and I correlated all the memory freed by the second HUP with what was allocated in the first HUP.It's perfect. Every block is freed.This is a fairly old installation, so old libraries, etc, but the very latest dnsmasq code.The configuration it's re-reading is pretty small. I then tried your technique of hitting dnsmasq hard with many HUPs.I had to go up to half a million to see much effect, but I guess most of those were dropped since they will have arrived before the previous one was cleared.In any case I could see a reproducible rise of a few percent in the VSZ of the process each time.What's clear is that the configuration is stored in a _lot_ of small allocations, so re-reading a substantial configuration will free a lot of small blocks and then malloc a lot of small blocks.A quick Google produces some complaints about the fragmentation performance of musl, which may be significant.Is your installation using musl as the C library, and is it possible to build dnsmasq against, say glibc to test?Nearly all of the memory management on dnsmasq that gets hit by answering DNS or DHCP requests avoid hammering the malloc system by building pools of free data structures that get re-cycled as needed. Once the pools have grown to equilibrium size, even a very busy server hardly uses the heap. I guess the configuration code to use the same policy, but it's a big re-write, and re-reading configuration on a sub-second timescale is an unlikely use-case.
* one access past the end of the iovec (reading past the iovcnt limit) that triggers AddressSanitizer reproducibly, in read_writev()
* one "variable may be used uninitialized" (I didn't check the logic, I just bluntly added = NULL to shut up the compiler) in dnssec code
* one patch that fixes undefined behavior, where base32_decode may shift into the sign bit which might wreak havoc on perverse C implementations (compiler & processor combination); I didn't test if as alternative, making the "oc" an unsigned integer could help, because for unsigned integers, wrapping is well-defined, but not for signed integers. We can clear the "oc" when we've written it.
I haven't seen a memory leak reported by address sanitizer yet, also valgrind in leak-checking mode on FreeBSD didn't holler.
To reproduce, add #define HAVE_DNSSEC to src/config.h, and change these three lines in Makefile - this assumes your debugger understands DWARF4 format and the compiler is reasonably compatible to GCC. You may need to tweak ASAN_OPTIONS=detect_leaks=1 to enable leak checking. Note the leak checker availability across operating systems is pretty limited. Systems that don't have it want to forgo that and use a different leak checker (valgrind might work).
CFLAGS = -Wall -W -Og -ggdb3 -gdwarf-4 -fno-omit-frame-pointer LDFLAGS = -fsanitize=address,undefined COPTS = -fsanitize=address,undefined
From 62582613d39a01475427b9996065b8974b7863e2 Mon Sep 17 00:00:00 2001 From: Matthias Andree <[email protected]> Date: Sat, 31 Jan 2026 23:22:30 +0100 Subject: [PATCH 1/3] base32_decode: avoid shifting into the sign bit While this won't do harm on systems that do 2's completement, it triggers the compilers' undefined-behavior sanitizer and fixes sanitizer error such as the one below (where the 1694... will vary) and is distracting while debugging. dnssec.c:1427:12: runtime error: left shift of 1694604366 by 1 places cannot be represented in type 'int' --- src/dnssec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/dnssec.c b/src/dnssec.c index c9cbacd..53153fc 100644 --- a/src/dnssec.c +++ b/src/dnssec.c @@ -1422,8 +1422,10 @@ static int base32_decode(char *in, unsigned char *out) if (c & mask) oc |= 1; mask = mask >> 1; - if (((++on) & 7) == 0) + if (((++on) & 7) == 0) { *p++ = oc; + oc = 0; + } oc = oc << 1; } } -- 2.52.0
From 3b460329b7f6d37c696274a8801c7e1cf406e29d Mon Sep 17 00:00:00 2001 From: Matthias Andree <[email protected]> Date: Sat, 31 Jan 2026 23:25:22 +0100 Subject: [PATCH 2/3] Avoid uninitialized-value warnings from the compiler --- src/dnssec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/dnssec.c b/src/dnssec.c index 53153fc..3e6ed02 100644 --- a/src/dnssec.c +++ b/src/dnssec.c @@ -1555,7 +1555,7 @@ static int prove_non_existence_nsec3(struct dns_header *header, size_t plen, uns { unsigned char *salt, *p, *digest; int digest_len, i, iterations, salt_len, base32_len, algo = 0; - struct nettle_hash const *hash; + struct nettle_hash const *hash = 0; char *closest_encloser, *next_closest, *wildcard; if (nons) -- 2.52.0
From e592c0330ac52a0c65ac147fddcfcf1f7c3b6620 Mon Sep 17 00:00:00 2001 From: Matthias Andree <[email protected]> Date: Sat, 31 Jan 2026 23:25:33 +0100 Subject: [PATCH 3/3] read_writev: avoid reading past the last iovec elem If iovcnt is exhausted and the first vector element's operation is satisfied, the while loop will read past the end of the iovec array. This triggers the address sanitizer and leads to undefined program state. Avoid reading too far. --- src/util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util.c b/src/util.c index 75971d3..59be5d7 100644 --- a/src/util.c +++ b/src/util.c @@ -790,7 +790,7 @@ int read_writev(int fd, struct iovec *iov, int iovcnt, int rw) return 0; done += n; - while ((size_t)done >= iov[cur].iov_len) + while (cur < iovcnt && (size_t)done >= iov[cur].iov_len) done -= iov[cur++].iov_len; } -- 2.52.0
_______________________________________________ Dnsmasq-discuss mailing list [email protected] https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。