[PATCH v2 0/2] Plug two memory leaks exposed via Meson
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Jan 30, 2025, 06:17 UTC
- Message-ID
- <20250130-b4-pks-memory-leaks-v2-0-fc29dc7d4b19@pks.im>
- In-Reply-To
- <20250129-b4-pks-memory-leaks-v1-0-79e41299eb0c@pks.im>
Hi,
I've had the need to play around with the memory leak sanitizer today and for the first time used it with Meson. Interestingly enough, a test run with Meson flags two memory leaks that our Makefile doesn't. I haven't found the time yet to figure out why that is, but this small patch series fixes both of these leaks.
Changes in v2:
- Add an explanation why t0301 only fails sometimes.
- Fix commit messages to properly point out the `-Db_sanitize=leak`
option.
- Link to v1: https://lore.kernel.org/r/20250129-b4-pks-memory-leaks-v1-0-79e41299eb0c@pks.imThanks!
Patrick
---
Patrick Steinhardt (2):
unix-socket: fix memory leak when chdir(3p) fails
scalar: free result of `remote_default_branch()`scalar.c | 4 +++- unix-socket.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-)
Range-diff versus v1:
1: 94205fa36f ! 1: 63fd407649 unix-socket: fix memory leak when chdir(3p) fails
@@ Commit message
with the original directory that we need to chdir(3p) back into, but
then the chdir(3p) into the socket's parent directory fails, then we
won't release the original directory's path. The leak is exposed by
- t0301, but only via Meson with `meson setup -Dsanitize=leak`:
+ t0301, but only when running tests in a directory hierarchy whose path
+ is long enough to make the socket name length exceed the maximum socket
+ name length:
Direct leak of 129 byte(s) in 1 object(s) allocated from:
#0 0x5555555e85c6 in realloc.part.0 lsan_interceptors.cpp.o
2: a4b4b31084 ! 2: 9248925ca0 scalar: free result of `remote_default_branch()`
@@ Commit message
We don't free the result of `remote_default_branch()`, leading to a
memory leak. This leak is exposed by t9211, but only when run with Meson
- via `meson setup -Dsanitize=leak`:
+ with the `-Db_sanitize=leak` option:
Direct leak of 5 byte(s) in 1 object(s) allocated from:
#0 0x5555555cfb93 in malloc (scalar+0x7bb93)
@@ Commit message
ever gets assigned the allocated string and free that one to plug the
leak.
+ It is unclear why the leak isn't flagged when running the test via our
+ Makefile.
+
Signed-off-by: Patrick Steinhardt <ps@pks.im>
## scalar.c ##--- base-commit: da898a5c645ce9b6d72c2d39abe1bc3d48cb0fdb change-id: 20250129-b4-pks-memory-leaks-2a318e5afec1