Re: [Valgrind-users] Boost Suppression Rules?

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

Hi Tom,

On Wed, Aug 24, 2011 at 2:20 AM, Tom Hughes <to...@co...> wrote:
> On 24/08/11 05:08, Jeffrey Walton wrote:
>
>> Does anyone have suppression rules for Boost? We're getting
>> overwhelmed with Boost squawks, and we are concerned Boost noise is
>> drowning out problems with our gear.
>>
>> A small sample is below from our run of about 30 self tests. For the
>> full run, there are about 12,000 lines, many which appear to be
>> related to Boost.
>>
>> On a side note, I don't ever recall seeing this many warnings from
>> Valgrind (even when testing large libraries such as Crypto++). Would
>> anyone know if Boost is doing something clever, or are there real
>> problems here (has someone previously investigated)?
>
> The problem is that you've told valgrind to report all memory that is still
> allocated,
Ah, ok. I was not aware it was a problem:

  ==16850== Reachable blocks (those to which a pointer was found) are not shown.
  ==16850== To see them, rerun with: --leak-check=full --show-reachable=yes

> but having allocated blocks that are still reachable at the end
> of the program is perfectly normal in most systems as most people are happy
> just to let the system discard the remaining memory on process exit rather
> than try and free it all.
Sloppy programming practices - the same kind of folks who try and free
null pointers.

We're working on a security library and we need assurances that
cleanup is being performed. Cleanup includes zeroizing sensitive,
in-memory materials in case the kernel serves up non-cleared pages.

These types of vulnerabilities do occur more frequently then one would
expect from elite kernel hackers. For example, were patched recently
(last week) in by Ubuntu, see USN-1190-1
(http://www.ubuntu.com/usn/usn-1189-1/).

> So it's not clear that, at least for any of the example messages you posted,
> there is any problem here.
Hmmmm... ok.

Jeff