pprof: symbolize mishandles the names of methods of parameterized Go types

[adonovan]

Using the version of pprof vendored in Go, the names of parameterized functions are mishandled so that a function named pkg.(*T[...]).f is rendered in SVG view as pkg \n \n f. The reason for the mishandling is that the C++ heuristic in Symbolize spuriously matches the square brackets, causing the parenthesized type name portion(*T[...]) to be removed.

This appears to be an effective workaround, but perhaps one can do better:

diff --git a/src/cmd/vendor/github.com/google/pprof/internal/symbolizer/symbolizer.go b/src/cmd/vendo
r/github.com/google/pprof/internal/symbolizer/symbolizer.go
index cbb0ed4d1b..90641a621e 100644
--- a/src/cmd/vendor/github.com/google/pprof/internal/symbolizer/symbolizer.go
+++ b/src/cmd/vendor/github.com/google/pprof/internal/symbolizer/symbolizer.go
@@ -231,7 +231,13 @@ func Demangle(prof *profile.Profile, force bool, demanglerMode string) {
                // Could not demangle. Apply heuristics in case the name is
                // already demangled.
                name := fn.SystemName
-               if looksLikeDemangledCPlusPlus(name) {
+
+               if strings.Contains(name, "[...]") {
+                       // Go parameterized function.
+                       // (Replace the periods so they don't get treated
+                       // as path separators later in dot view.)
+                       name = strings.ReplaceAll(name, "[...]", "[…]")
+               } else if looksLikeDemangledCPlusPlus(name) {
                        if demanglerMode == "" || demanglerMode == "templates" {
                                name = removeMatching(name, '(', ')')
                        }

Before:
With workaround:

@ianlancetaylor

[prattmic]

I think that detection of [...] could go directly in looksLikeDemangledCPlusPlus as a special case like the one for Java.

Dot will need to handle ... as well, but perhaps that should be handled directly in the dot generator code? (I'd also considered replacing ... with unicode ellipsis before I found this issue!)

There is another wrinkle here too, in that the actual symbol names look something like main.(*Foo[go.shape.string_0,go.shape.int_1]).Meth. In pprof profiling, Go simplifies the symbol name with [...], but a perf profile for example will still use the full symbol name, which ideally should not trip up pprof. Thus, I'd like to get looksLikeDemangledCPlusPlus to not match either main.(*Foo[...]).Meth or main.(*Foo[go.shape.string_0,go.shape.int_1]).Meth.

I took a look at the demangled symbols in a large C++ binary, and every instance of square brackets fell into one of two categories:

1. Nothing inside the brackets (e.g., new[], delete[], operator[], char []).
2. A single number inside the brackets (e.g., unsigned long const (&) [4]). I think these were all array types.

Neither of these patterns would appear in Go symbols, so we could match on either of these in looksLikeDemangledCPlusPlus. However, I am very familiar with C++ mangling, so I'm not sure if there are other possible uses of mangled square brackets in symbol names that I missed (cc @ianlancetaylor may know?).

[ianlancetaylor]

Here are some other cases where square brackets will appear in demangled C++ names. I don't know whether they matter.

_Z3fooPfS_S_j.sse4_1.2
foo(float*, float*, float*, unsigned int) [clone .sse4_1.2]

_Z1f1AIXtl1Xdi1adi1bdXLi3ELi4ELi1EEEE
f(A<X{.a.b[3 ... 4]=(1)}>)

_ZDC1a1bE
[a, b]

_ZNStDC1aEE
std::[a]

_ZW3FooDC1a1bE
[a, b]@Foo

_ZN3NMSW3MOD3FooB3ABIEv
NMS::Foo@MOD[abi:ABI]()

[prattmic]

Oof, wow. I, uh, love C++.

#717 handles only the two cases I described. The others will not be detected as C++, so function parameters and type parameters would not be removed when simplifying names (https://github.com/golang/go/blob/master/src/cmd/vendor/github.com/google/pprof/internal/symbolizer/symbolizer.go#L231).

I am also unsure how important these are either. This code is also only relevant if the profile contains symbol names that are already demangled, and it is unclear to me how common that is. I can also support a few more of these, but some like [a] are ambiguous with Go names depending on where in the name they can appear, so we can't do it perfectly.