From: Jeff King <peff@peff.net>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: git@vger.kernel.org
Subject: [PATCH 4/4] Makefile: turn on NO_MMAP when building with LSan
Date: Thu, 5 Mar 2026 18:13:05 -0500 [thread overview]
Message-ID: <20260305231305.GD2901305@coredump.intra.peff.net> (raw)
In-Reply-To: <20260305230315.GA2354983@coredump.intra.peff.net>
The past few commits fixed some cases where we leak memory allocated by
mmap(). Building with SANITIZE=leak doesn't detect these because it
covers only heap buffers allocated by malloc().
But if we build with NO_MMAP, our compat mmap() implementation will
allocate a heap buffer and pread() into it. And thus Lsan will detect
these leaks for free.
Using NO_MMAP is less performant, of course, since we have to use extra
memory and read in the whole file, rather than faulting in pages from
disk. But LSan builds are already slow, and this doesn't make them
measurably worse. Getting extra coverage for our leak-checking is worth
it.
Signed-off-by: Jeff King <peff@peff.net>
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index f3264d0a37..4cf1afd395 100644
--- a/Makefile
+++ b/Makefile
@@ -1600,6 +1600,7 @@ BASIC_CFLAGS += -DSHA1DC_FORCE_ALIGNED_ACCESS
endif
ifneq ($(filter leak,$(SANITIZERS)),)
BASIC_CFLAGS += -O0
+NO_MMAP = CatchMapLeaks
SANITIZE_LEAK = YesCompiledWithIt
endif
ifneq ($(filter address,$(SANITIZERS)),)
--
2.53.0.786.g466665faa3
next prev parent reply other threads:[~2026-03-05 23:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-05 20:51 memory leak when cloning a repository Jacob Keller
2026-03-05 22:02 ` Jeff King
2026-03-05 23:03 ` [PATCH 0/4] plugging some mmap() leaks Jeff King
2026-03-05 23:08 ` [PATCH 1/4] check_connected(): delay opening new_pack Jeff King
2026-03-05 23:18 ` Jacob Keller
2026-03-05 23:09 ` [PATCH 2/4] check_connected(): fix leak of pack-index mmap Jeff King
2026-03-05 23:20 ` Jacob Keller
2026-03-05 23:12 ` [PATCH 3/4] pack-revindex: avoid double-loading .rev files Jeff King
2026-03-05 23:13 ` Jeff King [this message]
2026-03-06 9:17 ` [PATCH 4/4] Makefile: turn on NO_MMAP when building with LSan Jacob Keller
2026-03-06 16:25 ` [PATCH 5/4] meson: " Jeff King
2026-03-06 18:00 ` Ramsay Jones
2026-03-07 1:14 ` [PATCH 4/4] Makefile: " Junio C Hamano
2026-03-07 2:24 ` [PATCH 3.5/4] object-file: fix mmap() leak in odb_source_loose_read_object_stream() Jeff King
2026-03-07 5:35 ` Junio C Hamano
2026-03-10 12:23 ` Patrick Steinhardt
2026-03-06 4:37 ` [PATCH 0/4] plugging some mmap() leaks Ramsay Jones
2026-03-06 16:21 ` Jeff King
2026-03-06 17:49 ` Ramsay Jones
2026-03-06 18:37 ` Junio C Hamano
2026-03-06 18:55 ` Ramsay Jones
2026-03-06 22:05 ` Junio C Hamano
2026-03-06 23:25 ` Ramsay Jones
2026-03-07 1:15 ` Junio C Hamano
2026-03-05 23:16 ` memory leak when cloning a repository Jacob Keller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260305231305.GD2901305@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=jacob.e.keller@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox