https://bugs.kde.org/show_bug.cgi?id=492389

            Bug ID: 492389
           Summary: Found nondeterminism in Valgrind's log for Memcheck
    Classification: Developer tools
           Product: valgrind
           Version: 3.18.1
          Platform: Ubuntu
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: memcheck
          Assignee: jsew...@acm.org
          Reporter: jo.al...@outlook.com
  Target Milestone: ---

Created attachment 173114
  --> https://bugs.kde.org/attachment.cgi?id=173114&action=edit
A one-page PDF resembling the file difference in Valgrind's log for Memcheck

Hi Valgrind Maintainers and Team!

I have been using Valgrind as a tool to check for nondeterministic behaviors
and I know that there are multiple subtools that Valgrind's suite comes with. I
would like to inquire about the Memcheck subtool in analyzing some of the
reports generated after each run against a binary. This nondeterminism concerns
the Valgrind generated report. Out of 41 repositories we've tested against
Memcheck, we saw that 25/41 showed flaky reportings for their respective
binaries. 

Would the respective team and its maintainers for this product take a look at
this issue and provide possible explanations? Thank you very much!

STEPS TO REPRODUCE
1. Use a GitHub Actions runner with Ubuntu 22.04 + Valgrind 3.18.1 pulled from
the Ubuntu package manager
2. Run your executable with Memcheck enabled. 
3. Obtain the Valgrind report

OBSERVED RESULT
We noticed that out of these 25 repositories that reported nondeterminism in
their Valgrind logs, we saw five distinct variations these logs experienced: 
  - difference in the byte-related metrics
  - differences of "still-reachable allocation" byte counts
  - differences in the memory and resource usage metrics (such as heap
statistics)
  - differences in the number of errors reported
  - difference in the performance metrics (like instruction counts and etc.). 

In the given attachment, the left column represents Run #1 while the right
column represents Run #2. As you notice, run #1 experienced two reported errors
relating to uninitialized value(s) while run #2 experienced no reported errors
and is 0. 

ADDITIONAL INFORMATION
See the attached PDF for the difference. Red and green resemble the differences
seen between the two runs.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to