david-christiansen / idris-tf-random Goto Github PK

EvanR:idris-tf-random evan$ idris --build tf-random.ipkg 
gcc -I. -fPIC -o idr_mash.so -shared idr_mash.c
Undefined symbols for architecture x86_64:
  "_Threefish_256_Process_Block", referenced from:
      _idr_Threefish_256_Process_Block in idr_mash-1hLsby.o
     (maybe you meant: _idr_Threefish_256_Process_Block)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [idr_mash.so] Error 1
Loading ./System/Random/TF/Gen.ibc failed: Could not load dynamic alternatives "idr_mash.so"

The needed symbol is in threefish_block.o but the gcc command for idr_mash.so does not include it.

http://lpaste.net/112156

In the above program, the last 4 or so out of 780 lines of output will vary from run to run.

This is really tricky. If you change the program slightly in some way that should or shouldn't change the behavior of the program, this will either cause the bug to apparently disappear (all output is reproducible from run to run) or cause it to manifest itself later in the sequence. By changing the random instance to give a Bits16 or Bits8 from the Bits32 random source (rather than wrapping it in a seemingly useless Word type) I have cause the bug to happen after ~70000 or ~12000 iterations instead of ~800. By removing the Word wrapper it seems to cause the bug to disappear completely.
By using the Bits32 generator directly (no Random instance) it seems to cause the bug to disappear completely. By inserting a pure () : IO () value before, after, or in the middle of the main loop it seems to cause the bug to disappear. By printing the values twice it seems to cause the bug to disappear. Printing the values as (Word, Bits32) to see if it is a problem with show instances seems to cause the bug to disappear!

I only tested this with the default C backend, not llvm or the repl.

Problem with tf-random's FFI code? If it is able to corrupt idris's C runtime that's a bigger issue. I was told that there is / may still be a spurious problem with BitsN primitives, and this may or may not be relevant to this.