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

[Zachary Turner via lldb-dev]

What about doing a partial demangle?   Take at most 1024 (for example)
characters from the mangled name, demangle that, and then display ... at
the end.

On Wed, Jan 24, 2018 at 3:48 PM Greg Clayton via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> 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:
>
>
> _ZNK3shk6detail17CallbackPublisherIZNS_5ThrowERKNSt15__exception_ptr13exception_ptrEEUlOT_E_E9SubscribeINS0_9ConcatMapINS0_18CallbackSubscriberIZNS_6GetAllIiNS1_IZZNS_9ConcatMapIZNS_6ConcatIJNS1_IZZNS_3MapIZZNS_7IfEmptyIS9_EEDaS7_ENKUlS6_E_clINS1_IZZNS_4TakeIiEESI_S7_ENKUlS6_E_clINS1_IZZNS_6FilterIZNS_9ElementAtEmEUlS7_E_EESI_S7_ENKUlS6_E_clINS1_IZZNSL_ImEESI_S7_ENKUlS6_E_clINS1_IZNS_4FromINS0_22InfiniteRangeContainerIiEEEESI_S7_EUlS7_E_EEEESI_S6_EUlS7_E_EEEESI_S6_EUlS7_E_EEEESI_S6_EUlS7_E_EEEESI_S6_EUlS7_E_EESI_S7_ENKUlS6_E_clIS14_EESI_S6_EUlS7_E_EERNS1_IZZNSH_IS9_EESI_S7_ENKSK_IS14_EESI_S6_EUlS7_E0_EEEEESI_DpOT_EUlS7_E_EESI_S7_ENKUlS6_E_clINS1_IZNS_5StartIJZNS_4JustIJS19_S1C_EEESI_S1F_EUlvE_ZNS1K_IJS19_S1C_EEESI_S1F_EUlvE0_EEESI_S1F_EUlS7_E_EEEESI_S6_EUlS7_E_EEEESt6vectorIS6_SaIS6_EERKT0_NS_12ElementCountEbEUlS7_E_ZNSD_IiS1Q_EES1T_S1W_S1X_bEUlOS3_E_ZNSD_IiS1Q_EES1T_S1W_S1X_bEUlvE_EES1G_S1O_E25ConcatMapValuesSubscriberEEEDaS7_
>
> 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
>
>
>
>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180124/253d8a9a/attachment.html>