{"thread":{"id":"58406","subject":"[PATCH] test-lib: ignore uninteresting LSan output","startedAt":"2022-09-08T05:17:19Z","lastAt":"2022-09-08T05:17:19Z","messageCount":1,"participants":["Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"462796","messageId":"Yxl62zODF4oy1QL9@coredump.intra.peff.net","threadId":"58406","inReplyTo":null,"subject":"[PATCH] test-lib: ignore uninteresting LSan output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-09-08T05:17:15Z","receivedAt":"2022-09-08T05:17:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"When I run the tests in leak-checking mode the same way our CI job does,\nlike:\n\n  make SANITIZE=leak \\\n       GIT_TEST_PASSING_SANITIZE_LEAK=true \\\n       GIT_TEST_SANITIZE_LEAK_LOG=true \\\n       test\n\nthen LSan can racily produce useless entries in the log files that look\nlike this:\n\n  ==git==3034393==Unable to get registers from thread 3034307.\n\nI think they're mostly harmless based on the source here:\n\n  https://github.com/llvm/llvm-project/blob/7e0a52e8e9ef6394bb62e0b56e17fa23e7262411/compiler-rt/lib/lsan/lsan_common.cpp#L414\n\nwhich reads:\n\n    PtraceRegistersStatus have_registers =\n        suspended_threads.GetRegistersAndSP(i, &registers, &sp);\n    if (have_registers != REGISTERS_AVAILABLE) {\n      Report(\"Unable to get registers from thread %llu.\\n\", os_id);\n      // If unable to get SP, consider the entire stack to be reachable unless\n      // GetRegistersAndSP failed with ESRCH.\n      if (have_registers == REGISTERS_UNAVAILABLE_FATAL)\n        continue;\n      sp = stack_begin;\n    }\n\nThe program itself still runs fine and LSan doesn't cause us to abort.\nBut test-lib.sh looks for any non-empty LSan logs and marks the test as\na failure anyway, under the assumption that we simply missed the failing\nexit code somehow.\n\nI don't think I've ever seen this happen in the CI job, but running\nlocally using clang-14 on an 8-core machine, I can't seem to make it\nthrough a full run of the test suite without having at least one\nfailure. And it's a different one every time (though they do seem to\noften be related to packing tests, which makes sense, since that is one\nof our biggest users of threaded code).\n\nWe can hack around this by only counting LSan log files that contain a\nline that doesn't match our known-uninteresting pattern.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nThis feels awfully hacky, and maybe we should just throw it away unless\nthe CI job starts having problems. But I literally couldn't get through\na run without false positives, so at the very least I wanted to make\npeople aware of the problem and get that string into the list archive. ;)\n\n t/test-lib.sh | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 377cc1c120..3951214cd5 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -324,6 +324,7 @@ nr_san_dir_leaks_ () {\n \tfind \"$TEST_RESULTS_SAN_DIR\" \\\n \t\t-type f \\\n \t\t-name \"$TEST_RESULTS_SAN_FILE_PFX.*\" 2>/dev/null |\n+\txargs grep -lv \"Unable to get registers from thread\" |\n \twc -l\n }\n \n-- \n2.37.3.1139.g47294c03c7\n\n\n"}]}