|
From: Joseph M L. <val...@jo...> - 2005-07-24 17:56:05
Attachments:
valgrind-src-supp-patch
|
Hey folks,
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).
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)
...
and
==21368== at 0x1B90469A: operator new[](unsigned)
(vg_replace_malloc.c:138)
==21368== by 0x8066EFC: shared_ptr<XmlNode> spnewT<XmlNode>(XmlNode*)
(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
}
{
allocator
Memcheck:Leak
fun:_Znaj
src:quick_allocator.hpp
}
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?
Thanks,
Joe
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-16 20:59:29
|
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?
Nick
|
|
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
|