[Bug binutils/29505] xxx-w64-mingw32-objdump takes a long time to scan pe binaries for debug information

[ralf.habacker at freenet dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=29505

--- Comment #1 from Ralf Habacker <ralf.habacker at freenet dot de> ---
(In reply to Ralf Habacker from comment #0)
> The question is whether objdump itself or in conjunction with the binaries
> used can cause this problem and if so, how to fix it.

At least objdump seems to have memory leaks

$ valgrind --leak-check=full i686-w64-mingw32-objdump -Wi bin/assistant.exe  >
/dev/null
==30665== Memcheck, a memory error detector
==30665== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==30665== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==30665== Command: i686-w64-mingw32-objdump -Wi bin/assistant.exe
==30665== 
==30665== 
==30665== HEAP SUMMARY:
==30665==     in use at exit: 745,472 bytes in 73 blocks
==30665==   total heap usage: 739,195 allocs, 739,122 frees, 125,826,656,614
bytes allocated
==30665== 
==30665== 221,184 bytes in 9 blocks are definitely lost in loss record 1 of 2
==30665==    at 0x4C338CF: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==30665==    by 0x24F99C: xrealloc (xmalloc.c:181)
==30665==    by 0x1722E8: UnknownInlinedFun (dwarf.c:10762)
==30665==    by 0x1722E8: read_and_display_attr_value (dwarf.c:2792)
==30665==    by 0x173DBF: UnknownInlinedFun (dwarf.c:3342)
==30665==    by 0x173DBF: process_debug_info (dwarf.c:3956)
==30665==    by 0x182A34: load_separate_debug_files (dwarf.c:11542)
==30665==    by 0x1619A6: dump_bfd (objdump.c:5028)
==30665==    by 0x1621EC: display_object_bfd (objdump.c:5221)
==30665==    by 0x1621EC: display_any_bfd (objdump.c:5311)
==30665==    by 0x1622B3: display_file (objdump.c:5332)
==30665==    by 0x15C58C: main (objdump.c:5700)
==30665== 
==30665== 524,288 bytes in 64 blocks are definitely lost in loss record 2 of 2
==30665==    at 0x4C312EF: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==30665==    by 0x24F9AF: xrealloc (xmalloc.c:179)
==30665==    by 0x1722E8: UnknownInlinedFun (dwarf.c:10762)
==30665==    by 0x1722E8: read_and_display_attr_value (dwarf.c:2792)
==30665==    by 0x173DBF: UnknownInlinedFun (dwarf.c:3342)
==30665==    by 0x173DBF: process_debug_info (dwarf.c:3956)
==30665==    by 0x182A34: load_separate_debug_files (dwarf.c:11542)
==30665==    by 0x1619A6: dump_bfd (objdump.c:5028)
==30665==    by 0x1621EC: display_object_bfd (objdump.c:5221)
==30665==    by 0x1621EC: display_any_bfd (objdump.c:5311)
==30665==    by 0x1622B3: display_file (objdump.c:5332)
==30665==    by 0x15C58C: main (objdump.c:5700)
==30665== 
==30665== LEAK SUMMARY:
==30665==    definitely lost: 745,472 bytes in 73 blocks
==30665==    indirectly lost: 0 bytes in 0 blocks
==30665==      possibly lost: 0 bytes in 0 blocks
==30665==    still reachable: 0 bytes in 0 blocks
==30665==         suppressed: 0 bytes in 0 blocks
==30665== 
==30665== For lists of detected and suppressed errors, rerun with: -s
==30665== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

-- 
You are receiving this mail because:
You are on the CC list for the bug.