If a C++ function name contains a substring like "{lambda()#1}", callgrind_annotate truncates it at the '#' and uses the truncated name for further processing. This can cause different functions to be merged, resulting in additional corruption. The problem exists because callgrind_annotate treats '#' as a comment marker anywhere on an input line and removes the "comment" before further processing. However, according to the format documentation, a comment must be on its own line, so a '#' in the middle of a line should *not* be treated as a comment marker.
Created attachment 123571 [details] callgrind_annotate: don't truncate function names at '#' Simple patch for fixing the problem: Skip comment lines instead of truncating after comment markers.
Thanks for the patch. Two small comments: * I am wondering if we should not allow comment lines starting with 0 or or spaces characters (like empty lines?) followed by # ? * cg_annotate seems to suffer from the same bug.
(In reply to Philippe Waroquiers from comment #2) > Thanks for the patch. > > Two small comments: > * I am wondering if we should not allow comment lines starting with > 0 or or spaces characters (like empty lines?) followed by # ? I wondered about that, too. Actually my first version allowed whitespace before the comment marker. But then I realized that callgrind_annotate doesn't skip spaces at the beginning of a line in other cases, either. Thus I adjusted my patch to be consistent with the rest of the logic. Do you know of a case where it would be necessary to allow whitespace before the comment marker? > * cg_annotate seems to suffer from the same bug. Ah, good point. I'll attach an updated patch with that change included.
Created attachment 123623 [details] Updated fix This version fixes the same issue with cg_annotate as well.
(In reply to Andreas Arnez from comment #3) > (In reply to Philippe Waroquiers from comment #2) > > * I am wondering if we should not allow comment lines starting with > > 0 or or spaces characters (like empty lines?) followed by # ? > I wondered about that, too. Actually my first version allowed whitespace > before the comment marker. But then I realized that callgrind_annotate > doesn't skip spaces at the beginning of a line in other cases, either. Thus > I adjusted my patch to be consistent with the rest of the logic. > Do you know of a case where it would be necessary to allow whitespace before > the comment marker? No, I had no specific example in mind, but as the callgrind format is quite general, I was afraid we might have a tool not in the valgrind tree producing such comment lines with spaces before #. I however just tried with kcachegrind, and it reports a warning for such # lines that have spaces before the #. So, I think that what you have done is ok.
Thanks for the analysis and patch, pushed in aaf64922a