[Bug sanitizer/80578] -fsanitize=undefined report yields memory leak

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue May 2 10:02:00 GMT 2017


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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #1)
> Confirmed, it's caused by fact that the vptr ubsan error calls demangler to
> display type name. That's the place where the memory is allocated and not
> properly released.
> 
> If you take a look at
> libsanitizer/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc, there's
> comment that confirms it's a known issue:
> 
> const char *DemangleCXXABI(const char *name) {
>   // FIXME: __cxa_demangle aggressively insists on allocating memory.
>   // There's not much we can do about that, short of providing our
>   // own demangler (libc++abi's implementation could be adapted so that
>   // it does not allocate). For now, we just call it anyway, and we leak
>   // the returned value.

The __cxxabiv1::__cxa_demangle behavior is mandated by the ABI, including the
fact that it invokes malloc and which way.


>   if (__cxxabiv1::__cxa_demangle)
>     if (const char *demangled_name =
>           __cxxabiv1::__cxa_demangle(name, 0, 0, 0))
>       return demangled_name;
> 
>   return name;
> }
> 
> I'm assigning that low priority.

libsupc++.a provides __gcclibcxx_demangle_callback alternative entrypoint next
to __cxa_demangle, with a callback where libsanitizer could take care of the
allocations or lack thereof (though, in that case it should really just be
printing it directly, because the callback can be called multiple times for
smaller parts of the demangled name) as it pleases.


More information about the Gcc-bugs mailing list