Test with count == 0 and optimization disabled trip a verify #528

The repro process is a bit involved, but it seems like there is a possible problem somewhere in the ecmult_multi logic (or in gcc itself).

Repro: Edit ./configure.ac to remove CFLAGS="$CFLAGS -O3" Then:

$ CFLAGS='-g -O0' ../configure --with-asm=no
$ make tests && ./tests 0
[compiling...]
test count = 0
random seed = 6a777122d5fd053929192734d4913476
../src/field_5x52_impl.h:421: test condition failed: b->magnitude <= 8
Aborted

It's unclear why this problem doesn't show up when the optimization are turned on. The compiler used is gcc 7.3.0 .

Neat! I can confirm that something funny happens in valgrind with ./tests 0. To be honest I had no idea this command was permissible -- my base case has always been ./tests 1.

I'll look into it. Solution may just be to require count ≥ 1.

I ended up having failures because of some test system that would run with zero because of some bug in the testing system.

My concern here isn't really that 0 is a very useful thing to test for, but that it put the system is some weird state that reveal a bug either in libsecp256k1 or possibly in gcc's optimizer. I'm not really up to speed with the ecmult_multi part of the code, so I'm unable to really help drill down further at this time.

No, it is purely that this line of code https://github.com/bitcoin-core/secp256k1/blob/master/src/tests.c#L2714 in the test jig is not run in the count==0 case, so a couple scalars are uninitialized, so the tests fail randomly. It has nothing to do with the library or with gcc.

I see. Thanks for getting to the bottom of this.