#9 RNG_test 0.93 crashes under Mac OS X using the stdin interface

[Sebastiano Vigna]

For example,

./xoroshiro128plus-stdout 55 14 36 1 1 | ./RNG_test stdin64 -tf 2 -te 1 -tlmaxonly
RNG = RNG_stdin64, PractRand version 0.92, seed = 0x8bb28b04
test set = expanded, folding = extra

Segmentation fault: 11

I tried to compile both using clang and using gcc.

Is this specific to stdin? I mean, if "stdin64" was changed to "sfc64" would the problem persist?

[Sebastiano Vigna]

It doesn't appear so:

./RNG_test sfc64 -tf 2 -te 1 -tlmaxonly
RNG_test using PractRand version 0.93
RNG = sfc64, seed = 0x8628def6
test set = expanded, folding = extra

Segmentation fault: 11

Note that clang gives some warnings (attached).

[Sebastiano Vigna]

RNG_test using PractRand version 0.93
RNG = sfc64, seed = 0x87b99f91
test set = expanded, folding = extra


Thread 2 received signal SIGSEGV, Segmentation fault.
0x0000000100052d03 in PractRand::Tests::DistC6::test_blocks (this=0x102827000, data=0x122600000, numblocks=4096) at src/tests.cpp:1631
1631                    index = _advance_index(index, lookup_table[count_bits16(data->as16[i++])]);
(gdb) p i
$1 = 2097153

Let me know if I can print other data that might be useful. It looks like an out-of-bounds array access, but I haven't checked the code.

That helps, I see the issue. The slower warmup code path for the first few bytes is switching over to the optimized path as soon as it can, and in doing so it violates the alignment contraint the optimized path has, so on the first call to test_blocks it ends up reading a couple bytes past the end of the buffer. Fixed for 0.94.

[Sebastiano Vigna]

If you want, I can test a beta.

Meh, I'm reasonably confident on this partcular issue, it's an error I introduced a few versions ago when optimizing things for very short test runs. Though I suppose there could be additional issues I haven't noticed...

But if you want a quick fix before I do the next release, well, the way it's set up there's no simple three-lines-or-less fix that works exactly right, but if you simply go to the end of DistC6::init() and round warmup up to the nearest multiple of 4, that will serve in a pinch.

That is:
warmup = length-1;
changed to:
warmup = (length - 1 + 3) & ~3;
will probably prevent it from reading past the end on the first test_blocks call, at the prices of shortening the usable data by up to 3 words (generally insignificant, but on a very short test run I suppose it could matter slightly) depending upon the parameterization used.

[Sebastiano Vigna]

"I don't do beta testing" would have been entirely sufficient. 😉

The 0.93 release and planned 0.94 release are both beta versions. I'm not currently planning to do private releases of either code patches or binaries between version numbers for this project.