Re: [DynInst_API:] [PATCH 1/2] common: rewrite caching in Linux P_cplus_demangle()

[Josh Stone <jistone@xxxxxxxxxx>]

On 07/31/2015 08:53 AM, Bill Williams wrote:
> On 07/30/2015 05:28 PM, Josh Stone wrote:
>> This had a bug where a last_typed value was saved even for parameter
>> includeTypes==false, where cplus_demangle opts lacked DMGL_PARAMS.
>> Similarly, the nativeCompiler parameter wasn't considered at all for
>> caching.
>>
>> This caused strange issues in boost::multi_index, where its internal
>> rehashing was sometimes allocating buffers incorrectly for its buckets.
>> This was because Symbol->getTypedName() was returning different values
>> depending on how P_cplus_demangle was cached, and silently changing keys
>> in a map is no good at all.
>>
>> P_cplus_demangle caching now requires an exact match on all three input
>> parameters before returning the saved result.
>>
> Approved, please apply. Do you happen to have a simple test case for 
> reproducing the bad behavior here?

Ok, I'll push it today.

I could probably write a testcase for the effective bug, something like
getTypedName(); getPrettyName(); getTypedName(); make sure it matches.
Or maybe a direct test of P_cplus_demangle caching.

But I don't have a testcase to target the boost::multi_index corruption
that I saw.  It was easily reproducible on Fedora 22 with:

  ./test_driver -create -pic -64 -test test5_1

This would crash libc with malloc corruption.  Under valgrind, it would
report boost's rehash function writing past the end of its allocation.

But this was a fickle error, and it took me a while to see what went
wrong.  Fedora 21 was fine with the exact same test.  I tried paying
with a lot of changed parameters between f21/f22, and could only find
that it crashed with dyninst on newer boost (built on either system),
targeting the mutatee built on f22 only.

Something in that exact build combination caused the boost rehash to
misbehave.  I finally got the thought to check the index stability, and
found this demangling inconsistency.  This happened everywhere, so I
suspect even the "working" configurations were just getting lucky that
boost didn't barf.