Bug 155125

Summary: avoid cutting away file:lineno after long function name
Product: [Developer tools] valgrind Reporter: Ren Lifeng <lfren>
Component: generalAssignee: Julian Seward <jseward>
Status: RESOLVED FIXED    
Severity: wishlist CC: flo2030, valgrind_bugzilla
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Ren Lifeng 2008-01-05 05:42:49 UTC
currently, valgrind use a buf of size 4096 to store error report(commentary).
when report error against template function, chance are big this limit is not
big enough. in this case file:lineno is cut away. i suggest to format the
commentary  like this:

==6605==    by 0x808E818: (astar_search.hpp:300) void
boost::astar_search<boost... 4000+ chars

or this

==6605==    by 0x808E818: void boost::astar_search<boost... 4000+ chars
(astar_search.hpp:300)
Comment 1 valgrind_bugzilla 2014-05-20 20:58:02 UTC
The bug is in UNCONFIRMED state, here is how to confirm it:
---------- valgrind-3.9.0 ----------
#!/bin/sh
# generate a function name around 5000 character long
long_function_name=leak_begin_$(yes 0123456789|head -n500|tr -d '\n')_end
# create a little program that leeks in this function
echo "void $long_function_name() { new char; } int main() { $long_function_name(); }" > leak.cpp;
g++ leak.cpp
# valgrind will report a leak BUT will not print the full function name (_end suffix),
# neither as the file name nor the line number.
valgrind --leak-check=full ./a.out
----------------------

One might think that a function so long could never occur in real code but with template recursive type lists and namespaces, it can be achieved pretty fast.
I myself run into it multiple time. It is frustrating to know that valgring found the bug (as always) but can not report it...
Comment 2 Florian Krohm 2014-11-18 10:10:24 UTC
As of r14685 function names are no longer truncated.
Filename and line numbers are no longer suppressed.
valgrind makes no attempt to shorten the function name as suggested in comment #1.
A heuristic that works well for somebody might not work for somebody else. So we don't want to go there. This sort of massaging is best done in an application specific postprocessing step.