dwz/backport-Fix-low-mem-memory-leak.patch
hugel 52f14c4d17 fix some memory leaks
(cherry picked from commit 6830d51939f9452bd7d21d23b20658bd236010bd)
2024-12-24 15:27:38 +08:00

97 lines
3.6 KiB
Diff

From 58080323488c5fd34793ae8c49f214b85eabe7f3 Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Wed, 24 Mar 2021 18:05:20 +0100
Subject: [PATCH] Fix low-mem memory leak
Conflict:NA
Reference:https://sourceware.org/git/?p=dwz.git;a=patch;h=58080323488c5fd34793ae8c49f214b85eabe7f3
When building dwz with -fsanitize=address, and running dwz in low-mem mode, we
run into a number of memory leaks:
...
$ dwz hello -o hello.z -l0
=================================================================
==22607==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 432 byte(s) in 6 object(s) allocated from:
#0 0x7f560af846d8 in __interceptor_calloc (/usr/lib64/libasan.so.4+0xdc6d8)
#1 0x475db1 in htab_try_create hashtab.c:164
#2 0x406ed6 in read_abbrev dwz.c:1296
#3 0x42bca9 in read_debug_info dwz.c:6818
#4 0x4608cb in read_dwarf dwz.c:13706
#5 0x46ef9a in dwz dwz.c:15383
#6 0x474a27 in dwz_one_file dwz.c:16279
#7 0x475951 in main dwz.c:16450
#8 0x7f560a8f9349 in __libc_start_main (/lib64/libc.so.6+0x24349)
Direct leak of 72 byte(s) in 1 object(s) allocated from:
#0 0x7f560af846d8 in __interceptor_calloc (/usr/lib64/libasan.so.4+0xdc6d8)
#1 0x475db1 in htab_try_create hashtab.c:164
#2 0x42a8fd in read_debug_info dwz.c:6634
#3 0x4608cb in read_dwarf dwz.c:13706
#4 0x46ef9a in dwz dwz.c:15383
#5 0x474a27 in dwz_one_file dwz.c:16279
#6 0x475951 in main dwz.c:16450
#7 0x7f560a8f9349 in __libc_start_main (/lib64/libc.so.6+0x24349)
Indirect leak of 4072 byte(s) in 1 object(s) allocated from:
#0 0x7f560af846d8 in __interceptor_calloc (/usr/lib64/libasan.so.4+0xdc6d8)
#1 0x475dd7 in htab_try_create hashtab.c:168
#2 0x42a8fd in read_debug_info dwz.c:6634
#3 0x4608cb in read_dwarf dwz.c:13706
#4 0x46ef9a in dwz dwz.c:15383
#5 0x474a27 in dwz_one_file dwz.c:16279
#6 0x475951 in main dwz.c:16450
#7 0x7f560a8f9349 in __libc_start_main (/lib64/libc.so.6+0x24349)
Indirect leak of 2928 byte(s) in 6 object(s) allocated from:
#0 0x7f560af846d8 in __interceptor_calloc (/usr/lib64/libasan.so.4+0xdc6d8)
#1 0x475dd7 in htab_try_create hashtab.c:168
#2 0x406ed6 in read_abbrev dwz.c:1296
#3 0x42bca9 in read_debug_info dwz.c:6818
#4 0x4608cb in read_dwarf dwz.c:13706
#5 0x46ef9a in dwz dwz.c:15383
#6 0x474a27 in dwz_one_file dwz.c:16279
#7 0x475951 in main dwz.c:16450
#8 0x7f560a8f9349 in __libc_start_main (/lib64/libc.so.6+0x24349)
SUMMARY: AddressSanitizer: 7504 byte(s) leaked in 14 allocation(s).
...
The leaks are related to the meta_abbrev_htab, which is allocated in
the initial read_debug_info call for .debug_info, and then allocated once more
in a second call to read_debug_info for .debug_types.
The second allocation overwrites the first one, and consequently the first one
is leaked.
Fix this by only allocating meta_abbrev_htab if not already allocated.
2021-03-23 Tom de Vries <tdevries@suse.de>
PR dwz/27633
* dwz.c (read_debug_info): Don't allocate meta_abbrev_htab if already
allocated.
---
dwz.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dwz.c b/dwz.c
index 92f8afa..c115b54 100644
--- a/dwz.c
+++ b/dwz.c
@@ -6628,7 +6628,8 @@ read_debug_info (DSO *dso, int kind, unsigned int *die_count)
if (dup_htab == NULL)
dwz_oom ();
}
- if (unlikely (op_multifile || rd_multifile || fi_multifile || low_mem))
+ if (unlikely (meta_abbrev_htab == NULL
+ && (op_multifile || rd_multifile || fi_multifile || low_mem)))
{
meta_abbrev_htab
= htab_try_create (500, meta_abbrev_hash, meta_abbrev_eq,
--
2.33.0