There is a 1 in 16 chance of a corruption escaping safe-linking and to guard against spurious failures, tst-safe-linking runs each subtest 10 times to ensure that the chance is reduced to 1 in 2^40. However, in the 1 in 16 chance that a corruption does escape safe linking, it could well be caught by other sanity checks we do in malloc, which then results in spurious test failures like below:
test test_fastbin_consolidate failed with a different error expected: malloc_consolidate(): unaligned fastbin chunk detected
actual: malloc_consolidate(): invalid chunk size
This failure is seen more frequently on i686; I was able to reproduce it in about 5 min of running it in a loop.
Guard against such failures by recording them and retrying the test. Also, do not fail the test if we happened to get defeated by the 1 in 2^40 odds if in at least one of the instances it was detected by other checks.
Finally, bolster the odds to 2^64 by running 16 times instead of 10. The test still has a chance of failure so it is still flaky in theory. However in practice if we see a failure here then it's more likely that there's a bug than it being an issue with the test. Add more printfs and also dump them to stdout so that in the event the test actually fails, we will have some data to try and understand why it may have failed.
191e406826 tst-safe-linking: make false positives even more improbable
malloc/tst-safe-linking.c | 31 +++++++++++++++++++++++++------
1 file changed, 25 insertions(+), 6 deletions(-)