[lldb-dev] Huge mangled names are causing long delays when loading symbol table symbols

Greg Clayton via lldb-dev lldb-dev at lists.llvm.org
Wed Jan 24 15:48:46 PST 2018

I have an issue where I am debugging a C++ binary that is around 250MB in size. It contains some mangled names that are crazy:


This de-mangles to something that is 72MB in size and takes 280 seconds (try running "time c++filt -n" on the above string).

There are probably many symbols likes this in this binary. Currently lldb will de-mangle all names in the symbol table so that we can chop up the names so we know function base names and we might be able to classify a base name as a method or function for breakpoint categorization.

My questions is: how do we work around such issues in LLDB? A few solutions I can think of:
1 - time each name demangle and if it takes too long somehow stop de-mangling similar symbols or symbols over a certain length? 
2 - allow a setting that says "don't de-mangle names that start with..." and the setting has a list of prefixes. 
3 - have a setting that turns off de-mangling symbols over a certain length all of the time with a default of something like 256 or 512
4 - modify our FastDemangler to abort if the de-mangled string goes over a certain limit to avoid bad cases like this...

#1 would still mean we get a huge delay (like 280 seconds) when starting to debug this binary, but might prevent multiple symbols from adding to that delay...

#2 would require debugging debugging once and then knowing which symbols took a while to de-mangle. If we time each de-mangle, we can warn that there are large mangled names and print the mangled name so the user might know?

#3 would disable de-mangling of long names at the risk of not de-mangling names that are close to the limit 

#4 requires that our FastDemangle code can decode the string mangled string. The fast de-mangler currently aborts on tricky de-mangling and we fall back onto cxa_demangle from the C++ library which doesn't not have a cutoff on length...

Can anyone else think of any other solutions?

Greg Clayton

More information about the lldb-dev mailing list