!25 [sync] PR-23: fix some memory leaks

From: @openeuler-sync-bot 
Reviewed-by: @dillon_chen 
Signed-off-by: @dillon_chen

backport-Fix-low-mem-memory-leak.patch

@@ -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
+

backport-Fix-memory-leak-in-build_abbrevs.patch

@@ -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
+

backport-Fix-memory-leak-in-write_multifile.patch

@@ -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
+

dwz.spec

@@ -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