|
From: Joseph M L. <val...@jo...> - 2005-08-16 22:14:26
|
Nicholas Nethercote wrote:
> On Sun, 24 Jul 2005, Joseph M Link wrote:
>
>> As I am sure you know, when using valgrind with inlined and -O2
>> optimized code, it becomes a little difficult to suppress based on
>> function name (as many calls are completely optimized away).
>
>
> Yes. We recommend compiling at lower levels of optimisation if possible
> for this reason.
>
>> For example, I would get reports such as:
>>
>> ==21368== at 0x1B90469A: operator new[](unsigned)
>> (vg_replace_malloc.c:138)
>> ==21368== by 0x806EE32: XmlNode::XmlNode(std::string const&,
>> std::string const&) (quick_allocator.hpp:97)
>>
>> The function I'd like to suppress is defined within
>> quick_allocator.hpp, but that call is inlined into every use of it.
>>
>> The attached patch adds support for suppression entries such as:
>>
>> {
>> allocator
>> Memcheck:Leak
>> fun:_Znaj
>> src:quick_allocator.hpp:97
>> }
>>
>> specifically, a 'src:' entry which can specify a source file with or
>> without a line number. This suppression would match both of the above
>> reports as long as debugging information is available in the
>> executable. If not, there is no detrimental effect, the suppression
>> just can't match.
>>
>> Any comments?
>
>
> This seems like not a bad idea. But why can't you suppress the above
> example? What does the output of --gen-suppressions=yes look like?
A function suppression can be created for the above example, but the
only function info that's available (the XmlNode constructor) is not the
function i want to suppress. It's the underlying allocator call that
has been optimized away that I want to suppress. In lieu of the
function call, I suppress at the particular line within the allocator
source code.
I should clarify that that XmlNode() constructor does *not* reside in
quick_allocator.hpp. I assume that the trace line is a mix of the last
function that actually has a frame and the real source line being executed.
Joe
|