This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Thu, 2017-08-17 at 11:59 +0100, Yao Qi wrote: > Alex Lindsay <alexlindsay239@gmail.com> writes: > > > I can verify that the objdump example is fixed in HEAD, but I still > > get this leak with `valgrind --leak-check=full > > --show-leak-kinds=definite gdb ./hello`: > > Yes, because your patch is not pushed in yet :) I tweaked your patch a > little bit, and pushed it in. Again, thanks for your contribution. Do > you still see other memory leak issues after this fix? > I still see significant leaks with 8.0.50.20170817-git Below a mail I sent to Pedro about this (IIUC, he last modified dwarf_decode_line_header memory management, which is the biggest leak I observed). Attached the new leaks. Philippe ------------------- Hello Pedro, Following some discussions on gdb patches, I wanted to run the gdb test suite under Valgrind, just in case it would leak. But before that, I did a small manual test, and with that, Valgrind already reports a significant leak, see below. So, it might be a little bit too early for me to run the full test suite :). The test consists in running a very small C executable, that does a loop of malloc calls: #include <stdlib.h> static void test() { void* leak __attribute__((unused)); int i; for (i = 0; i < 1000; i++) leak = (void*)malloc( 1 ); } int main() { test(); return 0; } I step inside this small executable to execute a few malloc calls, then do: thread apply all bt full info var .* info func .* x /s leak continue quit The biggest leak is as below. My knowledge of c++ is close to 0, so I cannot help much to find the source of the leak. I am wondering however who owns the memory allocated at dwarf2read.c:9362 : line_header_up lh = dwarf_decode_line_header (line_offset, cu); when the logic goes later on to line 9389 gdb_assert (die->tag != DW_TAG_partial_unit); (for info: in the c version 7.11, this assert was followed by make_cleanup (free_cu_line_header, cu); ) ==31555== 1,102,606 (124,592 direct, 978,014 indirect) bytes in 1,198 blocks are definitely lost in loss record 12,252 of 12,262 ==31555== at 0x4C28215: operator new(unsigned long) (vg_replace_malloc.c:334) ==31555== by 0x589266: dwarf_decode_line_header(sect_offset, dwarf2_cu*) (dwarf2read.c:17916) ==31555== by 0x58BD4C: handle_DW_AT_stmt_list (dwarf2read.c:9362) ==31555== by 0x58BD4C: read_file_scope (dwarf2read.c:9440) ==31555== by 0x58BD4C: process_die(die_info*, dwarf2_cu*) (dwarf2read.c:8503) ==31555== by 0x58FC97: process_full_comp_unit (dwarf2read.c:8289) ==31555== by 0x58FC97: process_queue (dwarf2read.c:7823) ==31555== by 0x58FC97: dw2_do_instantiate_symtab(dwarf2_per_cu_data*) (dwarf2read.c:2928) ==31555== by 0x590D85: dwarf2_read_symtab(partial_symtab*, objfile*) (dwarf2read.c:7689) ==31555== by 0x619E66: psymtab_to_symtab(objfile*, partial_symtab*) (psymtab.c:775) ==31555== by 0x61BC8C: psym_expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (char const*)>, gdb::function_view<void (compunit_symtab*)>, search_domain) (psymtab.c:1431) ==31555== by 0x64B7F5: expand_symtabs_matching(gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (char const*)>, gdb::function_view<void (compunit_symtab*)>, search_domain) (symfile.c:3834) ==31555== by 0x654E07: search_symbols(char const*, search_domain, int, char const**, symbol_search**) (symtab.c:4307) ==31555== by 0x655B9A: symtab_symbol_info(char*, search_domain, int) [clone .isra.57] (symtab.c:4557) ==31555== by 0x493808: cmd_func(cmd_list_element*, char*, int) (cli-decode.c:1902) ==31555== by 0x677AF5: execute_command(char*, int) (top.c:650) (there are more than 350 definely or possibly loss records in total with this small test, I am attaching the full leak report). Thanks Philippe Side question: is there a systematic run of gdb test suite under Valgrind (or similar tool) ? Once I (more or less) master what is happening, I might setup a night run of gdb test suite under Valgrind, but that might only be useful if gdb is relatively 'memcheck leak/error' free. As far as I can see, GDB 7.12 was quite 'leak-free' (the same test only leaked a few blocks) so it seems we can have significant regressions in that area.
Attachment:
leaks.out.xz
Description: application/xz
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |