Async-profiler: invalid char in flamechart output

[jurgenvinju]

Using async-profiler-1.6-macos-x64.tar.gz on a MBP running Java 8, I found this in an output SVG file:

<g>
<title>__block_descriptor_40_e8_32r_e31_v16
?0
"_CFPrefsClientContext"8l (1 samples, 0.03%)</title><rect x="706.5" y="2307.0" width="0.3" height="15" fill="#ec6969" rx="2" ry="2"/>
<text x="709.5" y="2318.0"></text>
</g>

In Chrome the following error message is rendered at the top of the page as a result: error on line 42773 at column 44: PCDATA invalid Char value 1. The block_descriptor title contains this weird character just before the " and just after the v16.

This issue is quite persistent when I profile for cpu events without the -t option. But with the -t option I never have it.

[apangin]

Do you know which module __block_descriptor_xxx symbol comes from?
If not, this patch may help to find one.

[jurgenvinju]

I've no idea. What exactly to do you mean by "module"?

[apangin]

I mean, a shared library / executable image that contains the symbol.

I've built a patched version that will output library name along with the symbol name: async-profiler-1.6-macos-x64.tar.gz

Can you please try this version and send the output (or at least the part of the output with the problematic symbol)?

[jurgenvinju]

will do! thanks

[jurgenvinju]

It contains several errors of the kind:

Uncaught TypeError: Cannot set property 'nodeValue' of undefined` on lines 46 and 52

and:

error on line 3493 at column 125: PCDATA invalid Char value 1

These are snippets (the first from 3493, and then onwards some repetitions of the same error:

<title>/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation::__block_descriptor_60_e8_32b40r_e8_v16
?0Q8l (2 samples, 0.04%)</title>
...
<title>/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation::__block_descriptor_60_e8_32b40r_e8_v16
?0Q8l (4 samples, 0.08%)</title>
...
<title>/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation::__block_descriptor_60_e8_32b40r_e8_v16
?0Q8l (16 samples, 0.34%)</title>

Interestingly, I grepped for the offending character code and it occurs always with CoreFoundationFramework and not with other prefixes, but not all CoreFoundation titles are wrong. See this one is ok:

<title>/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation::__CFBinaryPlistWriteOrPresize.arrayCallbacks (13 samples, 0.27%)</title>

The original file is too big to share here, so I dumped it as a gist for your reference. Pls tell me if/when I can remove that stuff again?

https://gist.github.com/jurgenvinju/8777f0d78470532b7b134d06c5ae7252

[jurgenvinju]

Some context, and one could probably derive that from the file: this is a profile of Eclipse. I'm exercising a a lot of scrolling of an SWT canvas during a 20sec CPU profile run.

I'm guessing from the mangled name that we're looking at the compiled code of an Objective C lambda expression that was given as a callback to the CoreFramework by SWT?

[apangin]

Thank you for the helpful info.
I can probably workaround the issue, but it's still not clear to me, if it is CoreFoundation binary that contains a bogus symbol, or there is something wrong with async-profiler's way to parse symbols.

I dumped all symbols in my CoreFoundation.framework, but didn't find anything suspicious.
What exact version of macOS are you running? Can you send me the result of

nm /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation

Thanks.

[jurgenvinju]

nmdump.txt

[jurgenvinju]

It contains the offending string, literally:

0000000000482670 s ___block_descriptor_60_e8_32b40r_e8_v16
?0Q8l

[jurgenvinju]

Looks like Objective C uses CTRL+A as a separator symbol in mangled lambda names:

0000000000489a10 s ___block_descriptor_72_e8_32o40o48o56o_e5_v8^A?0l
0000000000489e78 s ___block_descriptor_72_e8_32o40o48o_e29_v24^A?0^A"NSArray"8^A"NSError"16l
0000000000488738 s ___block_descriptor_72_e8_32o40r48r56r_e33_v16^A?0^A"NSObject<OS_xpc_object>"8
l

[jurgenvinju]

O, and I'm running Catalina 10.15.1 (19B88) on a MBP from 2014, with Xcode installed and a lot of other stuff using brew but that shouldn't affect CoreFramework (I hope).

[apangin]

Thanks for the update. This is another surprise of Catalina then...
Who on Earth would want to use non-printable characters in symbol names! Sigh...

OK, I'll make a workaround.

[apangin]

Hopefully, replacing non-printable characters with ? will be sufficient.
I've committed the fix.