#581 regression: assert "ddata->output.size > 0" in demangling caused by r3531

[Derek Bruening]

We use libelftc for demangling in the DynamoRIO project and recently I updated to a newer version and hit an assertion in our demangling test:

libelftc_dem_gnu3.c:2138: cpp_demangle_read_sname: Assertion `ddata->output.size > 0' failed.

That fires when demangling this symbol:

_ZZN7WebCore19SVGAnimatedProperty20LookupOrCreateHelperINS_32SVGAnimatedStaticPropertyTearOffIbEEbLb1EE21lookupOrCreateWrapperEPNS_10SVGElementEPKNS_15SVGPropertyInfoERbE19__PRETTY_FUNCTION__

You should be able to readily reproduce by demangling that symbol.

I tracked the assert down to r3531. r3531 also fixes a symbol that previously failed:

_ZN10linked_ptrIN12CrxInstaller14WhitelistEntryEE4copyIS1_EEvPKS_IT_E

But that was a graceful failure. This new assert indicates memory bugs and memory corruption.

FYI, our test demangles a series of symbols here:
https://github.com/DynamoRIO/dynamorio/blob/master/suite/tests/client-interface/drsyms-test.dll.cpp#L944

See also https://github.com/DynamoRIO/dynamorio/issues/4087#issuecomment-586031998.

[Andrey Valyaev]

I see this problem at FreeBSD-11.3

Assertion failed: (ddata->output.size > 0), function cpp_demangle_read_sname, file /usr/src/contrib/elftoolchain/libelftc/libelftc_dem_gnu3.c, line 2137.

Problem name is _ZZN5boost13serialization16singleton_module8get_lockEvE4lock

$ nm --version
nm (elftoolchain r3614M)

[Dimitry Andric]

Here's a three part fix set for the problems described above.

ticket581-1.diff:

Work around problem introduced in r3531

Ensure cpp_demangle_read_sname() checks ddata->cur_output, since it can be called with ddata->cur_output set to many different struct vector_str instances.

This fixes the "ddata->output.size > 0" assertion which occurs right when the demangling starts.

ticket581-2.diff:

Fix the second part of #581, which is about an assertion with nested template parameters.

demangle:
_ZZN7WebCore19SVGAnimatedProperty20LookupOrCreateHelperINS_32SVGAnimatedStaticPropertyTearOffIbEEbLb1EE21lookupOrCreateWrapperEPNS_10SVGElementEPKNS_15SVGPropertyInfoERbE19__PRETTY_FUNCTION__

to:
WebCore::SVGAnimatedProperty::LookupOrCreateHelper<webcore::svganimatedstaticpropertytearoff\<bool>, bool, true>::lookupOrCreateWrapper(WebCore::SVGElement, WebCore::SVGPropertyInfo const, bool&)::PRETTY_FUNCTION</webcore::svganimatedstaticpropertytearoff\<bool>

This fixes the next assertion you get, when demangling a name with nested template arguments (such as in the WebCore example above).

ticket582-3.diff:

When vector_str_push_vector() pushes a vector of size 1 onto a vector of size 0, as is usual in the beginning of demangling, the resulting vector gets a capacity of 1. Later on, this wreaks havoc when its capacity is multiplied by BUFFER_GROW_FACTOR, since this rounds down so the capacity cannot grow beyond 1!

Add a BUFFER_GROW() macro to ensure the calculation is correctly rounded, and always increases the capacity.

This fixes yet another assertion, when the first fixes have been applied.

[Joseph Koshy]

Added in [r3877], thanks!

[Joseph Koshy]

See also: ticket [#554].