git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[RFC PATCH 0/5] valgrind in test scripts

From
Jeff King <peff@peff.net>
Date
Oct 22, 2008, 20:28 UTC
Message-ID
<20081022202810.GA4439@coredump.intra.peff.net>

I spent some time last week running git through the paces with valgrind's memcheck tool. The good news is that I didn't find any serious issues, so we are doing a pretty good job overall. The bad news is that running the whole test suite with valgrind takes a few hours on a quad-core (but thank goodness for "make -j4 test").

I did uncover a few potential problems, and patches are in the latter part of the series. I suppose an argument could be made that these fixes are code churn, since these are not problems in practice, but I think they are worth fixing. The fixes are few in number and small, and we are very close to a valgrind-error-free code-base, which would make it easy to spot any new problems when they arise. We could always suppress these errors, but there is the possibility of an overzealous suppression masking a real problem (especially if one of these issues changes from theoretical to practical).

There are a few things I don't like:
 1. The "fake git PATH" is set up by the Makefile, since it needs to
    know which dashed commands to override (based on $(PROGRAMS)).
    I think it would be nicer if the test script itself set this up when
    --memcheck was requested, so that we always know it is fresh. But:
      - if the fake PATH isn't inside the trash directory, then we have
        a problem with multiple tests trying to set it up at the same
        time
      - if the fake PATH is inside the trash directory, I'm not sure of
        the best place to put it, as I don't want to influence the
        outcome of the tests. It could go into .git/valgrind, without
        hurting anything.
 2. I wanted to have a completely clean valgrind run before posting.
    With these patches, the only errors I get are for an uninitialized
    "struct stat" in t4121 and t4127. After much looking (including
    carefully reading the code, and using a a debugger, which shows the
    data in question looking very much initialized) I can't figure out
    what the problem might be. So it might simply be a false positive in
    valgrind, but I would like another set of eyes.
-Peff
Next: Jeff King
Message 1 of 13 in “valgrind in test scripts”
  1. 0/5 valgrind in test scriptsJeff King, Oct 22, 2008
  2. 1/5 add valgrind support in test scriptsJeff King, Oct 22, 2008
  3. Johannes SchindelinOct 22, 2008
  4. Junio C HamanoOct 23, 2008
  5. Jeff KingOct 23, 2008
  6. Jeff KingOct 23, 2008
  7. 2/5 valgrind: ignore ldso errorsJeff King, Oct 22, 2008
  8. 3/5 correct cache_entry allocationJeff King, Oct 22, 2008
  9. 4/5 pack-objects: avoid reading uninitalized dataJeff King, Oct 22, 2008
  10. Nicolas PitreOct 23, 2008
  11. Jeff KingOct 23, 2008
  12. Nicolas PitreOct 23, 2008
  13. 5/5 fix overlapping memcpy in normalize_absolute_pathJeff King, Oct 22, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.