Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
tests/valgrind: fix handling of forks
We tried to support valgrind checking of fork() in: 2023-09-20 tests/valgrind: improve handling for fork() and exec() 38e07b4 However, that method assumed that the first pid would be the parent, while the second (and subsequent ones) would be the children. That has two flaws: 1) if the pid rolls over, the order would be broken. For example, if the parent pid was 99999 on FreeBSD (the maxmimum value), then the child would be something much lower (probably in the hundreds). (I knew about that problem, considered it sufficiently unlikely.) 2) since $_valgrind_check_logfiles are defined by `ls "blah"*`, they are listed in lexicographical order, not numerical order. For example, given two logfiles foo-9999.log and foo-10000.log, foo-10000.log would come first. (I did not anticipate this problem, but even if it had occurred to me, I probably would have deemed it sufficiently unlikely. However, by unlikely fluke, this seems to occur roughly 50% of the time with github actions: when 24-fork-func with the gcc binaries, the parent lands on pid 9999 exactly and the child is 10000.) The fix is not to rely on the order: instead, generate a list of all pids involved. If a valgrind logfile lists a parent pid which is in that list, it's a child; otherwise, it's the parent.
- Loading branch information