diff --git a/backport-Fix-low-mem-memory-leak.patch b/backport-Fix-low-mem-memory-leak.patch new file mode 100644 index 0000000000000000000000000000000000000000..3eaf7d069ffc86f665562166ad662cafef293771 --- /dev/null +++ b/backport-Fix-low-mem-memory-leak.patch @@ -0,0 +1,96 @@ +From 58080323488c5fd34793ae8c49f214b85eabe7f3 Mon Sep 17 00:00:00 2001 +From: Tom de Vries +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 + + 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 + diff --git a/backport-Fix-memory-leak-in-build_abbrevs.patch b/backport-Fix-memory-leak-in-build_abbrevs.patch new file mode 100644 index 0000000000000000000000000000000000000000..61a48c3f960474ce0d21b83d60ebd31213d00019 --- /dev/null +++ b/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 +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 + + * 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 + diff --git a/backport-Fix-memory-leak-in-write_multifile.patch b/backport-Fix-memory-leak-in-write_multifile.patch new file mode 100644 index 0000000000000000000000000000000000000000..8ed8ec9f8f0246e7a5fd37d19872cfcbc223a63a --- /dev/null +++ b/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 +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 ) 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 + + 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 + diff --git a/dwz.spec b/dwz.spec index 4ff41782cfcddeeaf7a24d7a3842123958ff8203..eedd9393dc02ca03735512922d205259ad4900a6 100644 --- a/dwz.spec +++ b/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 - 0.14-5 +- fix some memory leaks + * Tue Oct 25 2022 yanglongkang - 0.14-4 - rebuild for next release