On Wed, 19 Mar 2025 23:00:55 GMT, Volodymyr Paprotski <vpaprot...@openjdk.org> wrote:
>> Randomness isn't idea for reproducibility. If a failure occurs, is it >> obvious what operations were done? I don't see any stdout or stderr >> messages to know what operations happen to bring about a possible failure. > > I used it this testcase for development (and figured I should also check it > in..) so what might be 'obvious' to me, might not be for anyone else? > > Typically, when a test failed, I grabbed the SEED from the test output, reran > the test with that seed fixed and I went to the exception and printed the hex > values of the inputs; (then debug from there. Typically, I would write > another test, so I could GDB into the intrinsic, with just those input > values). > > It was pretty much always the case always that once I got the inputs, I could > reproduce the error i.e. not a type of bug that happens silently then > discovered somewhere else. Luckily. All this crypto code is constant-time > -no-branches-; so the 'test coverage' here is not 'all-branches-taken' but > really 'did you remember to collect all the carries'. like 53-bit limb needs > to be propagated back down to 52. Thats what the test here is 'searching' > for, some input that could trip up computation. Can you add a comment to the test code about how you use the seed to reproduce any failures? So that in the future, someone who doesn't know will now have an idea how to start debugging this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2006142794
