thakis - Does your experience with demangling lead to you know what's wrong with these names? Other non-demanglable names I've come across were just the result of an obvious prefix/suffix added on by the linker. No idea what's wrong with these though.

My unverified guess is that this is a new c++14 mangling that demumble's itanium demangler is too old for. You could try cloning it and putting in the most recent demangler from libcxx(abi?) and see if that helps.

demumble isn't confused on my system:

$ ./demumble _ZNSt6__ndk112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6assignIPKtEENS_9enable_ifIXsr21__is_forward_iteratorIT_EE5valueERS5_E4typeESA_SA_
std::__ndk1::enable_if<__is_forward_iterator<unsigned short const*>::value, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >&>::type std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >::assign<unsigned short const*>(unsigned short const*, unsigned short const*)

Maybe your demumble doesn't have 9628c34f00dc25755954ee47383a5a55fed8389d (from may 2016)? That updated cxa_demangle

Clang's demangler seems to work for the first string. To build:

  tools/clang/scripts/update.py --force-local-build

or, if warning appears:

  tools/clang/scripts/update.py --force-local-build --without-android

To use:

  third_party/llvm-build/Release+Asserts/bin/llvm-cxxfilt _ZNSt6__ndk112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6assignIPKtEENS_9enable_ifIXsr21__is_forward_iteratorIT_EE5valueERS5_E4typeESA_SA_

Output:

std::__ndk1::enable_if<__is_forward_iterator<unsigned short const*>::value, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >&>::type std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >::assign<unsigned short const*>(unsigned short const*, unsigned short const*)

However, the '_ZSt5__ndk112..." string does not work.

For the _ZSt5__ndk112... case, it's only difference from the other case is '_ZSt5' vs. '_ZNSt6". It appears to be malformed:

- 'N' stands for nested name, and is terminated by 'E':
<nested-name> ::= N [<CV-qualifiers>] <prefix> <unqualified-name> E
              ::= N [<CV-qualifiers>] <template-prefix> <template-args> E

- 5 vs. 6 is name of token, which in this case is '__ndk1', i.e., length-6.

So this should be a toolchain bug, not SuperSize bug.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

In 918716 estevenson@ found more (new?) examples of demangle failure, e.g., 

   _ZN12_GLOBAL__N_124AAFlatteningConvexPathOp19onCombineIfPossibleEP4GrOpRK6GrCaps$39a714be4038aec63642597f522dad6f

The key feature here is '$' followed by 32 hex digits.

Naively stripping anything after '$' is undesirable because there are symbols that contain '$'!

It seems adequate to just detect and strip trailing '$' followed by 32 hex digits when we demangle.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b919b3c6065c47953cf9d0f66f0689dcb7799db8

commit b919b3c6065c47953cf9d0f66f0689dcb7799db8
Author: Samuel Huang <huangs@chromium.org>
Date: Mon Jan 07 19:06:55 2019

[SuperSize] Strip hex hash suffixes of symbol before demangling.

Chrome APK still has ~9100 symbols that start with '_Z' for
which SuperSize fails to demangle. The failure is due to the presence
of a length-33 suffix, consisting of '$' followed by 32 lowercase hex
digits.

This CL updates demangle.py to detect and strip these suffixes, so
symbols can properly demangle.

Bug: 766903
Change-Id: I6a039219624a6cc4ed29742bae417d19e329ca6c
Reviewed-on: https://chromium-review.googlesource.com/c/1396600
Reviewed-by: Eric Stevenson <estevenson@chromium.org>
Reviewed-by: Samuel Huang <huangs@chromium.org>
Commit-Queue: Samuel Huang <huangs@chromium.org>
Cr-Commit-Position: refs/heads/master@{#620408}
[modify] https://crrev.com/b919b3c6065c47953cf9d0f66f0689dcb7799db8/tools/binary_size/libsupersize/demangle.py

 Issue 746993  has been merged into this issue.

Noticed another form of this: https://storage.googleapis.com/chrome-supersize/viewer.html?load_url=https%3A%2F%2Fstorage.googleapis.com%2Fchromium-binary-size-trybot-results%2Fandroid-binary-size%2F2019%2F01%2F18%2F138755%2Fsupersize_diff.ndjson&diff_mode=on

re #11 - I don't think it's a demangling issue. Just filed bug 923936 to track that one.