Discovered with LLVM libFuzzer (http://llvm.org/docs/LibFuzzer.html). Using current binutils trunk (libiberty is identical to r244484): valgrind --leak-check=full build/binutils/cxxfilt __ELztype_31__tp__H1f_H1f0U_F0U_Fv__F__ELztype_31__tp__H1f0U_FS (signed) __ELztype_31__tp__H1f_H1f0U_F0U_Fv__F__ELztype_31__tp<0>(void) ==24094== HEAP SUMMARY: ==24094== in use at exit: 9 bytes in 2 blocks ==24094== total heap usage: 33 allocs, 31 frees, 888 bytes allocated ==24094== ==24094== 9 (8 direct, 1 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 2 ==24094== at 0x40307C4: malloc (valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c:270) ==24094== by 0x7D1157: xmalloc (/build/libiberty/../../libiberty/xmalloc.c:147) ==24094== by 0x7BD245: demangle_template (/build/libiberty/../../libiberty/cplus-dem.c:2232) ==24094== by 0x7C05E5: demangle_signature (/build/libiberty/../../libiberty/cplus-dem.c:1695) ==24094== by 0x7C0994: iterate_demangle_function (/build/libiberty/../../libiberty/cplus-dem.c:2747) ==24094== by 0x7C1598: internal_cplus_demangle (/build/libiberty/../../libiberty/cplus-dem.c:2975) ==24094== by 0x7BC491: cplus_demangle (/build/libiberty/../../libiberty/cplus-dem.c:922) ==24094== by 0x405643: demangle_it (/build/binutils/../../binutils/cxxfilt.c:62) ==24094== by 0x40525B: main (/build/binutils/../../binutils/cxxfilt.c:227) ==24094== ==24094== LEAK SUMMARY: ==24094== definitely lost: 8 bytes in 1 blocks ==24094== indirectly lost: 1 bytes in 1 blocks ==24094== possibly lost: 0 bytes in 0 blocks ==24094== still reachable: 0 bytes in 0 blocks ==24094== suppressed: 0 bytes in 0 blocks The same leak was definitely present as early as 2016/10/09. The version of binutils imported from head on 2016/06/09 does not appear to have this leak.
Confirmed.
<shameless plug> We are already fuzzing the LLVM demangler on https://github.com/google/oss-fuzz (a free continuous fuzzing service for OSS). Binutils demangler is very welcome there as well. </shameless plug>