This is an archive of the discontinued LLVM Phabricator instance.

[compiler-rt] Demangling for DlAddrSymbolizer
ClosedPublic

Authored by kubamracek on Mar 12 2015, 7:17 AM.

Details

Reviewers
samsonov
Summary

On OS X, dladdr() provides mangled names only, so we need need to demangle in DlAddrSymbolizer::SymbolizePC.

Diff Detail

Event Timeline

kubamracek updated this revision to Diff 21828.Mar 12 2015, 7:17 AM
kubamracek retitled this revision from to [compiler-rt] Demangling for DlAddrSymbolizer.
kubamracek updated this object.
kubamracek edited the test plan for this revision. (Show Details)
kubamracek added subscribers: Unknown Object (MLST), zaks.anna, samsonov and 2 others.
zaks.anna added inline comments.Mar 12 2015, 10:09 AM
lib/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc
42

Maybe we should provide an option that allows us to turn off demangling? It would make it easier to isolate cases where we get a second failure while reporting. Clients who don't need this (ex: running under the debugger) could turn this off.

What do you think?

kubamracek added inline comments.Mar 12 2015, 10:21 AM
lib/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc
42

Can demangling really cause such a bad failure? I was under the impression that either __cxa_demangle could be missing (because we're not linked against libcxx) or it could return NULL, and we handle both these cases here. (Which reminds me that the extra check for NULL-ness above in sanitizer_symbolizer_mac.cc is not necessary, because DemangleCXXABI can never return NULL).

However, if you suspect that it could actually cause a crash, having an option to turn it on/off sounds like a good idea.

FYI, if you use ASAN_OPTIONS=symbolize=0, stack traces will not be symbolicated at all, and no demangling will occur either.

I've just noticed this FIXME in the comment:
" __cxa_demangle aggressively insists on allocating memory."

Allocating memory while in a bad state could result in unpredictable behavior.

samsonov accepted this revision.Mar 12 2015, 5:37 PM
samsonov added a reviewer: samsonov.

FYI I'm ok with this patch. Allocating memory during report printing is bad, will roundtrip through our allocator, and can cause different side-effects. However, we can't do much better here. InternalSymbolizer we're using internally allocates a *lot* of memory, and we were able to get away with it for quite a while for now.

This revision is now accepted and ready to land.Mar 12 2015, 5:37 PM
kubamracek closed this revision.Mar 22 2015, 4:44 AM

Landed in r232910. Later I'll try to take another look into memory allocations during report printing.