public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libbacktrace/105240] New: backtrace_pcinfo leaks memory
@ 2022-04-12 14:49 redi at gcc dot gnu.org
  2022-04-12 14:50 ` [Bug libbacktrace/105240] " redi at gcc dot gnu.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2022-04-12 14:49 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240

            Bug ID: 105240
           Summary: backtrace_pcinfo leaks memory
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libbacktrace
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
                CC: ian at gcc dot gnu.org
  Target Milestone: ---

I'm seeing lots of leaked memory for simple uses of libbacktrace:

$ valgrind --leak-check=full  ./stacktrace
==297621== Memcheck, a memory error detector
==297621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==297621== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==297621== Command: ./stacktrace
==297621== 
==297621== 
==297621== HEAP SUMMARY:
==297621==     in use at exit: 699,881 bytes in 1,134 blocks
==297621==   total heap usage: 2,469 allocs, 1,335 frees, 1,473,361 bytes
allocated
==297621== 
==297621== 2,286 bytes in 53 blocks are definitely lost in loss record 12 of 20
==297621==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==297621==    by 0x4113F5: __glibcxx_backtrace_alloc (alloc.c:57)
==297621==    by 0x413672: read_lnct (dwarf.c:2543)
==297621==    by 0x413672: read_line_header_format_entries (dwarf.c:2618)
==297621==    by 0x415286: read_line_header (dwarf.c:2712)
==297621==    by 0x415286: read_line_info (dwarf.c:2965)
==297621==    by 0x415286: dwarf_lookup_pc (dwarf.c:3747)
==297621==    by 0x4162B0: dwarf_fileline (dwarf.c:3935)
==297621==    by 0x405B95:
std::stacktrace_entry::_M_get_info(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >*,
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
>*, int*) const (stacktrace:186)
==297621==    by 0x405885: std::stacktrace_entry::source_line() const
(stacktrace:129)
==297621==    by 0x404B08: test_assign() (stacktrace.cc:132)
==297621==    by 0x40554E: main (stacktrace.cc:212)
==297621== 
==297621== 46,055 bytes in 1 blocks are possibly lost in loss record 17 of 20
==297621==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==297621==    by 0x4113F5: __glibcxx_backtrace_alloc (alloc.c:57)
==297621==    by 0x4112EA: __glibcxx_backtrace_get_view (read.c:68)
==297621==    by 0x410CC3: elf_add.constprop.0 (elf.c:4381)
==297621==    by 0x4111E3: __glibcxx_backtrace_initialize (elf.c:4877)
==297621==    by 0x40BC47: fileline_initialize (fileline.c:261)
==297621==    by 0x40BCE5: __glibcxx_backtrace_pcinfo (fileline.c:295)
==297621==    by 0x405B95:
std::stacktrace_entry::_M_get_info(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >*,
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
>*, int*) const (stacktrace:186)
==297621==    by 0x405885: std::stacktrace_entry::source_line() const
(stacktrace:129)
==297621==    by 0x404B08: test_assign() (stacktrace.cc:132)
==297621==    by 0x40554E: main (stacktrace.cc:212)
==297621== 
==297621== LEAK SUMMARY:
==297621==    definitely lost: 2,286 bytes in 53 blocks
==297621==    indirectly lost: 0 bytes in 0 blocks
==297621==      possibly lost: 46,055 bytes in 1 blocks
==297621==    still reachable: 651,540 bytes in 1,080 blocks
==297621==         suppressed: 0 bytes in 0 blocks
==297621== Reachable blocks (those to which a pointer was found) are not shown.
==297621== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==297621== 
==297621== For lists of detected and suppressed errors, rerun with: -s
==297621== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)


This only happens when libbacktrace uses malloc instead of mmap.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libbacktrace/105240] backtrace_pcinfo leaks memory
  2022-04-12 14:49 [Bug libbacktrace/105240] New: backtrace_pcinfo leaks memory redi at gcc dot gnu.org
@ 2022-04-12 14:50 ` redi at gcc dot gnu.org
  2022-04-12 14:52 ` redi at gcc dot gnu.org
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2022-04-12 14:50 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-04-12
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This simple C++ program:

#include <backtrace.h>

int cb_pcinfo(void*, uintptr_t, const char*, int, const char* function)
{ return function != nullptr; }

int cb(void* p, uintptr_t pc) { *static_cast<uintptr_t*>(p) = pc; return 1; }

int main()
{
  auto state = backtrace_create_state(nullptr, 1, nullptr, nullptr);
  uintptr_t pc;
  backtrace_simple(state, 0, cb, nullptr, &pc);
  backtrace_pcinfo(state, pc, cb_pcinfo, nullptr, nullptr);
}


Built with:

g++ bt.cc build/libbacktrace/.libs/libbacktrace.a -I
~/src/gcc/gcc/libbacktrace/ -g

When run under valgrind shows:

valgrind --leak-check=full  ./a.out
==410984== Memcheck, a memory error detector
==410984== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==410984== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==410984== Command: ./a.out
==410984== 
==410984== 
==410984== HEAP SUMMARY:
==410984==     in use at exit: 112,638,104 bytes in 729,676 blocks
==410984==   total heap usage: 729,861 allocs, 185 frees, 115,412,593 bytes
allocated
==410984== 
==410984== 84 bytes in 3 blocks are definitely lost in loss record 5 of 43
==410984==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==    by 0x409283: read_lnct (dwarf.c:2543)
==410984==    by 0x409283: read_line_header_format_entries (dwarf.c:2618)
==410984==    by 0x40B08A: read_line_header (dwarf.c:2712)
==410984==    by 0x40B08A: read_line_info (dwarf.c:2965)
==410984==    by 0x40B08A: dwarf_lookup_pc (dwarf.c:3747)
==410984==    by 0x40C1BE: dwarf_fileline (dwarf.c:3935)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== 13,920 bytes in 1 blocks are definitely lost in loss record 25 of 43
==410984==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==    by 0x406ED6: backtrace_get_view (read.c:68)
==410984==    by 0x40568A: elf_get_view (elf.c:426)
==410984==    by 0x40568A: elf_add (elf.c:4329)
==410984==    by 0x406BC8: phdr_callback (elf.c:4848)
==410984==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==    by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== 31,248 bytes in 1 blocks are possibly lost in loss record 28 of 43
==410984==    at 0x48456AF: realloc (vg_replace_malloc.c:1437)
==410984==    by 0x407115: backtrace_vector_release (alloc.c:159)
==410984==    by 0x40CDCD: build_dwarf_data (dwarf.c:3976)
==410984==    by 0x40CDCD: backtrace_dwarf_add (dwarf.c:4022)
==410984==    by 0x406475: elf_add (elf.c:4749)
==410984==    by 0x4060E9: elf_add (elf.c:4434)
==410984==    by 0x406BC8: phdr_callback (elf.c:4848)
==410984==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==    by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== 69,736 bytes in 2 blocks are possibly lost in loss record 30 of 43
==410984==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==    by 0x406ED6: backtrace_get_view (read.c:68)
==410984==    by 0x40568A: elf_get_view (elf.c:426)
==410984==    by 0x40568A: elf_add (elf.c:4329)
==410984==    by 0x406BC8: phdr_callback (elf.c:4848)
==410984==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==    by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== 164,768 bytes in 1 blocks are possibly lost in loss record 31 of 43
==410984==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==    by 0x406ED6: backtrace_get_view (read.c:68)
==410984==    by 0x405C50: elf_add (elf.c:4591)
==410984==    by 0x406BC8: phdr_callback (elf.c:4848)
==410984==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==    by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== 174,888 bytes in 3 blocks are possibly lost in loss record 32 of 43
==410984==    at 0x48456AF: realloc (vg_replace_malloc.c:1437)
==410984==    by 0x407115: backtrace_vector_release (alloc.c:159)
==410984==    by 0x40CDAA: build_dwarf_data (dwarf.c:3974)
==410984==    by 0x40CDAA: backtrace_dwarf_add (dwarf.c:4022)
==410984==    by 0x406475: elf_add (elf.c:4749)
==410984==    by 0x4060E9: elf_add (elf.c:4434)
==410984==    by 0x406BC8: phdr_callback (elf.c:4848)
==410984==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==    by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== 231,094 bytes in 1 blocks are possibly lost in loss record 33 of 43
==410984==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==    by 0x406ED6: backtrace_get_view (read.c:68)
==410984==    by 0x405C50: elf_add (elf.c:4591)
==410984==    by 0x406D83: backtrace_initialize (elf.c:4877)
==410984==    by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== 308,808 bytes in 3 blocks are possibly lost in loss record 35 of 43
==410984==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==    by 0x4067B5: elf_initialize_syminfo (elf.c:661)
==410984==    by 0x4067B5: elf_add (elf.c:4392)
==410984==    by 0x406BC8: phdr_callback (elf.c:4848)
==410984==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==    by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== 438,981 bytes in 4 blocks are possibly lost in loss record 36 of 43
==410984==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==    by 0x406ED6: backtrace_get_view (read.c:68)
==410984==    by 0x40667B: elf_add (elf.c:4381)
==410984==    by 0x406BC8: phdr_callback (elf.c:4848)
==410984==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==    by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== 767,840 bytes in 4,799 blocks are possibly lost in loss record 37 of
43
==410984==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==    by 0x40C54F: build_address_map (dwarf.c:2183)
==410984==    by 0x40C54F: build_dwarf_data (dwarf.c:3969)
==410984==    by 0x40C54F: backtrace_dwarf_add (dwarf.c:4022)
==410984==    by 0x406475: elf_add (elf.c:4749)
==410984==    by 0x4060E9: elf_add (elf.c:4434)
==410984==    by 0x406BC8: phdr_callback (elf.c:4848)
==410984==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==    by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== 16,608,019 (72 direct, 16,607,947 indirect) bytes in 1 blocks are
definitely lost in loss record 40 of 43
==410984==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==    by 0x401773: backtrace_create_state (state.c:66)
==410984==    by 0x401308: main (bt.cc:10)
==410984== 
==410984== 18,629,920 bytes in 5,066 blocks are possibly lost in loss record 41
of 43
==410984==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==    by 0x40C747: read_abbrevs (dwarf.c:1409)
==410984==    by 0x40C747: build_address_map (dwarf.c:2197)
==410984==    by 0x40C747: build_dwarf_data (dwarf.c:3969)
==410984==    by 0x40C747: backtrace_dwarf_add (dwarf.c:4022)
==410984==    by 0x406475: elf_add (elf.c:4749)
==410984==    by 0x4060E9: elf_add (elf.c:4434)
==410984==    by 0x406BC8: phdr_callback (elf.c:4848)
==410984==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==    by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== 21,644,094 bytes in 5 blocks are possibly lost in loss record 42 of
43
==410984==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==    by 0x406ED6: backtrace_get_view (read.c:68)
==410984==    by 0x405C50: elf_add (elf.c:4591)
==410984==    by 0x4060E9: elf_add (elf.c:4434)
==410984==    by 0x406BC8: phdr_callback (elf.c:4848)
==410984==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==    by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== 53,554,704 bytes in 575,533 blocks are possibly lost in loss record
43 of 43
==410984==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==    by 0x40CB1E: read_abbrevs (dwarf.c:1457)
==410984==    by 0x40CB1E: build_address_map (dwarf.c:2197)
==410984==    by 0x40CB1E: build_dwarf_data (dwarf.c:3969)
==410984==    by 0x40CB1E: backtrace_dwarf_add (dwarf.c:4022)
==410984==    by 0x406475: elf_add (elf.c:4749)
==410984==    by 0x4060E9: elf_add (elf.c:4434)
==410984==    by 0x406BC8: phdr_callback (elf.c:4848)
==410984==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==    by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==    by 0x40134E: main (bt.cc:13)
==410984== 
==410984== LEAK SUMMARY:
==410984==    definitely lost: 14,076 bytes in 5 blocks
==410984==    indirectly lost: 16,607,947 bytes in 144,253 blocks
==410984==      possibly lost: 96,016,081 bytes in 585,418 blocks
==410984==    still reachable: 0 bytes in 0 blocks
==410984==                       of which reachable via heuristic:
==410984==                         newarray           : 4,064 bytes in 1 blocks
==410984==         suppressed: 0 bytes in 0 blocks
==410984== 
==410984== For lists of detected and suppressed errors, rerun with: -s
==410984== ERROR SUMMARY: 14 errors from 14 contexts (suppressed: 0 from 0)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libbacktrace/105240] backtrace_pcinfo leaks memory
  2022-04-12 14:49 [Bug libbacktrace/105240] New: backtrace_pcinfo leaks memory redi at gcc dot gnu.org
  2022-04-12 14:50 ` [Bug libbacktrace/105240] " redi at gcc dot gnu.org
@ 2022-04-12 14:52 ` redi at gcc dot gnu.org
  2022-04-12 16:31 ` ian at airs dot com
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2022-04-12 14:52 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I thought it would be OK to just use the malloc configuration unconditionally
within libstdc++, but it looks like I need to include the configure checks for
mman.h and use mmap whenever possible. It might even be better to disable the
std::stacktrace feature entirely if mmap isn't available, so we don't get these
malloc leaks.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libbacktrace/105240] backtrace_pcinfo leaks memory
  2022-04-12 14:49 [Bug libbacktrace/105240] New: backtrace_pcinfo leaks memory redi at gcc dot gnu.org
  2022-04-12 14:50 ` [Bug libbacktrace/105240] " redi at gcc dot gnu.org
  2022-04-12 14:52 ` redi at gcc dot gnu.org
@ 2022-04-12 16:31 ` ian at airs dot com
  2022-04-12 17:39 ` redi at gcc dot gnu.org
  2022-04-12 21:39 ` cvs-commit at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: ian at airs dot com @ 2022-04-12 16:31 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #3 from Ian Lance Taylor <ian at airs dot com> ---
mmap is definitely preferred.  The malloc implementation is only there to
support systems without mmap.

That said I'm not sure I understand the valgrind report.  Some of that memory
is not lost as long as the program has a pointer to the backtrace_state.  It's
true that there is no way to release all memory allocated by the state.  That
is not a goal, as I expect that programs will allocate a backtrace_state and
use it until the program is complete.  What kinds of reports do you see if you
put the backtrace_state in a global variable?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libbacktrace/105240] backtrace_pcinfo leaks memory
  2022-04-12 14:49 [Bug libbacktrace/105240] New: backtrace_pcinfo leaks memory redi at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2022-04-12 16:31 ` ian at airs dot com
@ 2022-04-12 17:39 ` redi at gcc dot gnu.org
  2022-04-12 21:39 ` cvs-commit at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2022-04-12 17:39 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The report in comment 0 is from libstdc++ which uses a local static variable to
hold the state.

Modifying the comment 1 example to use a global:

#include <backtrace.h>

int cb_pcinfo(void*, uintptr_t, const char*, int, const char* function)
{ return function != nullptr; }

int cb(void* p, uintptr_t pc) { *static_cast<uintptr_t*>(p) = pc; return 1; }

backtrace_state* state;

int main()
{
  state = backtrace_create_state(nullptr, 1, nullptr, nullptr);
  uintptr_t pc;
  backtrace_simple(state, 0, cb, nullptr, &pc);
  backtrace_pcinfo(state, pc, cb_pcinfo, nullptr, nullptr);
}

I get:

==494586== Memcheck, a memory error detector
==494586== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==494586== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==494586== Command: ./a.out
==494586== 
==494586== 
==494586== HEAP SUMMARY:
==494586==     in use at exit: 112,638,181 bytes in 729,676 blocks
==494586==   total heap usage: 729,861 allocs, 185 frees, 115,412,694 bytes
allocated
==494586== 
==494586== 84 bytes in 3 blocks are definitely lost in loss record 6 of 35
==494586==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==494586==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==494586==    by 0x409283: read_lnct (dwarf.c:2543)
==494586==    by 0x409283: read_line_header_format_entries (dwarf.c:2618)
==494586==    by 0x40B08A: read_line_header (dwarf.c:2712)
==494586==    by 0x40B08A: read_line_info (dwarf.c:2965)
==494586==    by 0x40B08A: dwarf_lookup_pc (dwarf.c:3747)
==494586==    by 0x40C1BE: dwarf_fileline (dwarf.c:3935)
==494586==    by 0x401357: main (bt.cc:15)
==494586== 
==494586== 2,839 bytes in 1 blocks are possibly lost in loss record 19 of 35
==494586==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==494586==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==494586==    by 0x406ED6: backtrace_get_view (read.c:68)
==494586==    by 0x40667B: elf_add (elf.c:4381)
==494586==    by 0x406D83: backtrace_initialize (elf.c:4877)
==494586==    by 0x4014B1: fileline_initialize (fileline.c:261)
==494586==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==494586==    by 0x401357: main (bt.cc:15)
==494586== 
==494586== 13,920 bytes in 1 blocks are definitely lost in loss record 23 of 35
==494586==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==494586==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==494586==    by 0x406ED6: backtrace_get_view (read.c:68)
==494586==    by 0x40568A: elf_get_view (elf.c:426)
==494586==    by 0x40568A: elf_add (elf.c:4329)
==494586==    by 0x406BC8: phdr_callback (elf.c:4848)
==494586==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==494586==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==494586==    by 0x4014B1: fileline_initialize (fileline.c:261)
==494586==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==494586==    by 0x401357: main (bt.cc:15)
==494586== 
==494586== 69,736 bytes in 2 blocks are possibly lost in loss record 26 of 35
==494586==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==494586==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==494586==    by 0x406ED6: backtrace_get_view (read.c:68)
==494586==    by 0x40568A: elf_get_view (elf.c:426)
==494586==    by 0x40568A: elf_add (elf.c:4329)
==494586==    by 0x406BC8: phdr_callback (elf.c:4848)
==494586==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==494586==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==494586==    by 0x4014B1: fileline_initialize (fileline.c:261)
==494586==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==494586==    by 0x401357: main (bt.cc:15)
==494586== 
==494586== 451,020 bytes in 7 blocks are possibly lost in loss record 31 of 35
==494586==    at 0x484086F: malloc (vg_replace_malloc.c:381)
==494586==    by 0x406FF1: backtrace_alloc (alloc.c:57)
==494586==    by 0x406ED6: backtrace_get_view (read.c:68)
==494586==    by 0x40667B: elf_add (elf.c:4381)
==494586==    by 0x406BC8: phdr_callback (elf.c:4848)
==494586==    by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==494586==    by 0x406DDD: backtrace_initialize (elf.c:4892)
==494586==    by 0x4014B1: fileline_initialize (fileline.c:261)
==494586==    by 0x401581: backtrace_pcinfo (fileline.c:295)
==494586==    by 0x401357: main (bt.cc:15)
==494586== 
==494586== LEAK SUMMARY:
==494586==    definitely lost: 14,004 bytes in 4 blocks
==494586==    indirectly lost: 0 bytes in 0 blocks
==494586==      possibly lost: 523,595 bytes in 10 blocks
==494586==    still reachable: 112,100,582 bytes in 729,662 blocks
==494586==         suppressed: 0 bytes in 0 blocks
==494586== Reachable blocks (those to which a pointer was found) are not shown.
==494586== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==494586== 
==494586== For lists of detected and suppressed errors, rerun with: -s
==494586== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)

So that's still 14kB definitely lost, 500kB possibly lost.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libbacktrace/105240] backtrace_pcinfo leaks memory
  2022-04-12 14:49 [Bug libbacktrace/105240] New: backtrace_pcinfo leaks memory redi at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2022-04-12 17:39 ` redi at gcc dot gnu.org
@ 2022-04-12 21:39 ` cvs-commit at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-04-12 21:39 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:3c742621ed28540cf42d4cfbc2bf03433cd26738

commit r12-8125-g3c742621ed28540cf42d4cfbc2bf03433cd26738
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Apr 12 17:56:45 2022 +0100

    libstdc++: Prefer to use mmap instead of malloc in libbacktrace

    As reported in PR libbacktrace/105240, libbacktrace leaks memory when
    using malloc for allocations. I originally thought it would be simpler
    to just use malloc unconditionally (because it's supported on all
    targets) but the leaks make that problematic.

    This adds libbacktrace's detection for mmap to the libstdc++
    configury, so that we use mmap.c and mmapio.c when possible. This avoids
    the leaks seen previously, at least on linux.

    libstdc++-v3/ChangeLog:

            * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Check for mmap.
            * config.h.in: Regenerate.
            * configure: Regenerate.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-04-12 21:39 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-12 14:49 [Bug libbacktrace/105240] New: backtrace_pcinfo leaks memory redi at gcc dot gnu.org
2022-04-12 14:50 ` [Bug libbacktrace/105240] " redi at gcc dot gnu.org
2022-04-12 14:52 ` redi at gcc dot gnu.org
2022-04-12 16:31 ` ian at airs dot com
2022-04-12 17:39 ` redi at gcc dot gnu.org
2022-04-12 21:39 ` cvs-commit at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).