This is an archive of the discontinued LLVM Phabricator instance.

[LIBC] Strengthen `pthread_join` tests; NFC
Needs ReviewPublic

Authored by goldstein.w.n on Apr 20 2023, 1:16 PM.

Details

Diff Detail

Event Timeline

goldstein.w.n created this revision.Apr 20 2023, 1:16 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptApr 20 2023, 1:16 PM
goldstein.w.n requested review of this revision.Apr 20 2023, 1:16 PM

Fix rand_val for iters

Fix join check

I like the general idea of having a more thorough test for pthreads as a whole, but it should probably be in a separate file instead of replacing the pthread_join test. I think it would fit better in the pthread_test file.

libc/test/integration/src/pthread/pthread_join_test.cpp
2

nit: fix header

Thanks @michaelrj for responding on this review. @goldstein.w.n - the tests you have added are great but couple of reasons for why I was putting this review off and eventually forgot about it: 1. The logic was not straightforward enough that without proper comments, I have to read through line by line to understand what exactly is going on. 2. Use of random values and I wanted to spend time to see what would be good alternates. Thanks to @michaelrj, I have actually read this patch in detail and have couple of comments:

  1. The non-null join test is best suited as a fuzz test. See examples here: https://github.com/llvm/llvm-project/tree/main/libc/fuzzing/stdlib
  2. For this patch, make an equivalent of the non-null join test which is deterministic (as in it does not use random numbers).

We do not run any of libc's fuzz tests on public infrastructure but we do run them downstream. If you can convert the test into a fuzz test, it might actually become complicated enough that we can make an attempt at running it on OSS-fuzz: https://github.com/google/oss-fuzz

Thanks @michaelrj for responding on this review. @goldstein.w.n - the tests you have added are great but couple of reasons for why I was putting this review off and eventually forgot about it: 1. The logic was not straightforward enough that without proper comments, I have to read through line by line to understand what exactly is going on. 2. Use of random values and I wanted to spend time to see what would be good alternates. Thanks to @michaelrj, I have actually read this patch in detail and have couple of comments:

Fair enough regarding the comments, can properly document.

  1. The non-null join test is best suited as a fuzz test. See examples here: https://github.com/llvm/llvm-project/tree/main/libc/fuzzing/stdlib

Why is that? Its really just checking that the runtime 1) returns the correct value and 2) doesn't return early.
I can drop the detached aspect if thats getting in the way.

I don't really see the fuzz aspect of it. There are no invalid joins (or at least I hope not) and its not really meant
to stress the system in some way to see if breaks down.

  1. For this patch, make an equivalent of the non-null join test which is deterministic (as in it does not use random numbers).

The random values are seeded with with srand(123) which should make the test entirely deterministic.

We do not run any of libc's fuzz tests on public infrastructure but we do run them downstream. If you can convert the test into a fuzz test, it might actually become complicated enough that we can make an attempt at running it on OSS-fuzz: https://github.com/google/oss-fuzz

  1. The non-null join test is best suited as a fuzz test. See examples here: https://github.com/llvm/llvm-project/tree/main/libc/fuzzing/stdlib

Why is that? Its really just checking that the runtime 1) returns the correct value and 2) doesn't return early.
I can drop the detached aspect if thats getting in the way.

The random values are seeded with with srand(123) which should make the test entirely deterministic.

I agree it is entirely deterministic. In which case, I would prefer a hand-crafted series without reliance on [s]rand. I am suggesting a fuzz test because you can do two things better: a) The test actually get a real random input. b) The test will get stress tested. But, if you eliminate the use of [s]rand, I will leave it up to you if you want to add a fuzz test at all.