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

linux-leaks CI failure on master

From
Taylor Blau <me@ttaylorr.com>
Date
Oct 18, 2022, 18:37 UTC
Message-ID
<Y07yeEQu+C7AH7oN@nand.local>

After Junio pushed out the tags for v2.38.1 and friends, I noticed that our linux-leaks CI job is failing t1300.104 and t1300.109, claiming that there is a leak here:

    Direct leak of 7 byte(s) in 1 object(s) allocated from:
    #0 0x7fc4a5b319c1 in __interceptor_malloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:54
    #1 0x7fc4a598638e in __GI___strdup /build/glibc-SzIz7B/glibc-2.31/string/strdup.c:42
    #2 0x55ba23538f7c in xstrdup wrapper.c:39
    #3 0x55ba233e258c in git_config_string config.c:1445
    #4 0x55ba233e6b06 in git_config_include config.c:439
    #5 0x55ba233e063f in get_value config.c:910
    #6 0x55ba233e063f in git_parse_source config.c:1092
    #7 0x55ba233e063f in do_config_from config.c:1937
    #8 0x55ba233e3d2d in do_config_from_file config.c:1965
    #9 0x55ba233e3d2d in git_config_from_file_with_options config.c:1987
    #10 0x55ba233e4793 in git_config_from_file config.c:1996
    #11 0x55ba233e4793 in do_git_config_sequence config.c:2143
    #12 0x55ba233e4793 in config_with_options config.c:2198
    #13 0x55ba233e4a50 in read_early_config config.c:2255
    #14 0x55ba233acb36 in alias_lookup alias.c:35
    #15 0x55ba232d0748 in handle_alias git.c:346
    #16 0x55ba232d0748 in run_argv git.c:851
    #17 0x55ba232d0748 in cmd_main git.c:921
    #18 0x55ba232cee03 in main common-main.c:57
    #19 0x7fc4a590b082 in __libc_start_main ../csu/libc-start.c:308
    #20 0x55ba232cee8d in _start (git+0x1fe8d)

I can't reproduce the failure locally with gcc (Debian 10.3.0-15) 10.3.0, but Victoria (CC'd) can reproduce the failure with 9.4.0. Interestingly, the failure only appears when compiling with `-O2`, but not `-O0` or `-O1`.

This is reminiscent to me of the discussion in:
  https://lore.kernel.org/git/Yy4eo6500C0ijhk+@coredump.intra.peff.net/

I'm not sure if I'm content to treat the 9.4.0 behavior as a compiler bug, but definitely running the linux-leaks build with `-O2` is suspicious.

I suppose we could temporarily mark t1300 as not passing with SANITIZE=leak turned on, but I tend to agree with Peff that that feels like a hack working around compiler behavior, that will ultimately result in us playing whack-a-mole.

So my preference would be to run the linux-leaks build with `-O0` in its CFLAGS, optionally with a newer compiler if one is available for Focal.

Thoughts?

Thanks, Taylor

Next: Jeff King
Message 1 of 8 in “linux-leaks CI failure on master”
  1. Taylor BlauOct 18, 2022
  2. Jeff KingOct 18, 2022
  3. Makefile: force -O0 when compiling with SANITIZE=leakJeff King, Oct 18, 2022
  4. Ævar Arnfjörð BjarmasonOct 18, 2022
  5. Jeff KingOct 19, 2022
  6. Rubén JustoOct 20, 2022
  7. Jeff KingOct 21, 2022
  8. Junio C HamanoOct 19, 2022

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.