Re: [Valgrind-users] Detect Global Offset Table (GOT) changes or corruption?

[Jeffrey W. <nol...@gm...>]

> A few Linux and Apple users report unexpected results and I am having
> trouble reproducing the issue. I have not been able to duplicate it,
> even, say on Debian Sid (unstable) with the bleeding edge GCC. Its
> been tough to narrow down, but it appears to be related to the latest
> GCC and possibly Clang compilers. I also suspect it might be related
> to the use of PIC.

We tracked this down to Debian Sid (unstable) running on real Core2
Duo hardware (I had to dust off an old Dell S1555 laptop). I also
needed the Debian maintainer to tar his VM and send it to me.

It appears the GCC 5.2.1 compiler was too aggressive with
-fdevirtualize for a few functions when the definition of the function
is in the header and its inlined.

The functions had a call to SecureByteBlock class, which manages an
array of bytes and zeroizes it on destruction. The function New does
what you would expect - it allocates a new block of memory. It can
also be used to reallocate if the new size is larger then when
created. GCC was omitting some of the calls to New which grew the
array.

Jeff