packages/dwz
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

fix some memory leaks

Browse Source 
(cherry picked from commit 6830d51939f9452bd7d21d23b20658bd236010bd)
This commit is contained in:
hugel 2024-12-24 13:55:23 +08:00 committed by openeuler-sync-bot
parent 936e1af665
commit 52f14c4d17
4 changed files with 257 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
backport-Fix-low-mem-memory-leak.patch Normal file
View File

@ -0,0 +1,96 @@
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

48
backport-Fix-memory-leak-in-build_abbrevs.patch Normal file
View File

@ -0,0 +1,48 @@
From d0e071f159b072ce985bc8397e98ef25fe788047 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 memory leak in build_abbrevs
Conflict:NA
Reference:https://sourceware.org/git/?p=dwz.git;a=patch;h=d0e071f159b072ce985bc8397e98ef25fe788047
I noticed that build_abbrevs leaks h in case the "return 1" path is taken:
...
htab_t h = htab_try_create (50, abbrev_hash, abbrev_eq2, NULL);
if (h == NULL)
dwz_oom ();
if (build_abbrevs_for_die (h, cu, cu->cu_die, NULL, NULL, t, ndies, vec,
false))
return 1;
...
Fix this by calling htab_delete before returning 1.
2021-03-24 Tom de Vries <tdevries@suse.de>
* dwz.c (build_abbrevs): Clean up in case of return 1.
---
dwz.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/dwz.c b/dwz.c
index b212d6d..436bae1 100644
--- a/dwz.c
+++ b/dwz.c
@@ -11234,7 +11234,10 @@ build_abbrevs (dw_cu_ref cu, struct abbrev_tag *t, unsigned int *ndies,
if (build_abbrevs_for_die (h, cu, cu->cu_die, NULL, NULL, t, ndies, vec,
false))
- return 1;
+ {
+ htab_delete (h);
+ return 1;
+ }
cu->cu_new_abbrev = h;
return 0;
--
2.33.0

106
backport-Fix-memory-leak-in-write_multifile.patch Normal file
View File

@ -0,0 +1,106 @@
From e948e307737dd7034692b886b07522aba8c98415 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 memory leak in write_multifile
Conflict:NA
Reference:https://sourceware.org/git/?p=dwz.git;a=patch;h=e948e307737dd7034692b886b07522aba8c98415
When building dwz with -fsanitize=address, we run into some memory leaks:
...
$ cp hello 1; ./dwz 1; cp 1 2; ./dwz -m 3 1 2
./dwz: 1: DWARF compression not beneficial - old size 3372 new size 3372
./dwz: 2: DWARF compression not beneficial - old size 3372 new size 3372
=================================================================
==8024==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 432 byte(s) in 6 object(s) allocated from:
#0 0x7f7ab92cc6d8 in __interceptor_calloc \
(/usr/lib64/libasan.so.4+0xdc6d8)
#1 0x475dc1 in htab_try_create hashtab.c:164
#2 0x44c610 in build_abbrevs dwz.c:11230
#3 0x44ee00 in compute_abbrevs dwz.c:11510
#4 0x46f07c in dwz dwz.c:15396
#5 0x474e0d in dwz_files_1 dwz.c:16327
#6 0x475699 in dwz_files dwz.c:16417
#7 0x4759fc in main dwz.c:16458
#8 0x7f7ab8c41349 in __libc_start_main (/lib64/libc.so.6+0x24349)
Indirect leak of 2928 byte(s) in 6 object(s) allocated from:
#0 0x7f7ab92cc6d8 in __interceptor_calloc \
(/usr/lib64/libasan.so.4+0xdc6d8)
#1 0x475de7 in htab_try_create hashtab.c:168
#2 0x44c610 in build_abbrevs dwz.c:11230
#3 0x44ee00 in compute_abbrevs dwz.c:11510
#4 0x46f07c in dwz dwz.c:15396
#5 0x474e0d in dwz_files_1 dwz.c:16327
#6 0x475699 in dwz_files dwz.c:16417
#7 0x4759fc in main dwz.c:16458
#8 0x7f7ab8c41349 in __libc_start_main (/lib64/libc.so.6+0x24349)
SUMMARY: AddressSanitizer: 3360 byte(s) leaked in 12 allocation(s).
...
A more concrete way to show some of the leaks is by using this patch on
build_abbrevs:
...
+ assert (cu->cu_new_abbrev == NULL);
cu->cu_new_abbrev = h;
return 0;
}
...
which triggers here:
...
#4 0x00000000004211b1 in build_abbrevs (cu=0x7ffff65f0e38, t=0x64e640,
ndies=0x7fffffffd81c, vec=0x649280 <ob2>) at dwz.c:11239
#5 0x0000000000421db2 in compute_abbrevs (dso=0x0) at dwz.c:11511
#6 0x000000000042fa2c in write_multifile (dso=0x64c210)
at dwz.c:15104
...
We could just do a htab_delete in build_abbrevs, which takes care of all the
leaks detected by the assert.
But write_multifile drops CUs from the cu list if
cu->cu_die->die_no_multifile == 1, and if a dropped CU has cu->cu_new_abbrev
!= NULL then cu_new_abbrev is still leaked.
Fix this by calling htab_delete in the loop that drops the CUs.
2021-03-24 Tom de Vries <tdevries@suse.de>
PR dwz/27643
* dwz.c (write_multifile): Clean up cu->cu_new_abbrev to fix memory
leak.
---
dwz.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/dwz.c b/dwz.c
index c115b54..b212d6d 100644
--- a/dwz.c
+++ b/dwz.c
@@ -15092,10 +15092,15 @@ write_multifile (DSO *dso)
dw_cu_ref *cup;
for (cup = &first_cu; *cup && (*cup)->cu_kind != CU_TYPES; )
- if ((*cup)->cu_die->die_no_multifile == 0)
- cup = &(*cup)->cu_next;
- else
- *cup = (*cup)->cu_next;
+ {
+ if ((*cup)->cu_new_abbrev)
+ htab_delete ((*cup)->cu_new_abbrev);
+
+ if ((*cup)->cu_die->die_no_multifile == 0)
+ cup = &(*cup)->cu_next;
+ else
+ *cup = (*cup)->cu_next;
+ }
*cup = NULL;
multifile_mode = MULTIFILE_MODE_WR;
if (tracing)
--
2.33.0

8
dwz.spec
View File

@ -1,12 +1,15 @@
Name: dwz
Version: 0.14
Release: 4
Release: 5
Summary: A DWARF optimization and duplicate removal tool
License: GPLv2+ and GPLv3+
URL: https://sourceware.org/dwz/
Source0:https://sourceware.org/ftp/dwz/releases/%{name}-%{version}.tar.xz
Patch1: testsuite-Handle-readelf-following-links-by-default.patch
Patch2: backport-Fix-low-mem-memory-leak.patch
Patch3: backport-Fix-memory-leak-in-write_multifile.patch
Patch4: backport-Fix-memory-leak-in-build_abbrevs.patch
BuildRequires:gcc elfutils-libelf-devel dejagnu gcc-c++ gdb
@ -54,6 +57,9 @@ make check
%{_mandir}/man1/dwz*
%changelog
* Tue Dec 24 2024 hugel <gengqihu2@h-partners.com> - 0.14-5
- fix some memory leaks
* Tue Nov 14 2023 renhongxun <renhongxun@h-partners.com> - 0.14-4
- revert version to 0.14