Open rmcgibbo opened 2 years ago
For what it's worth, the results are stable from run to run when:
twox_hash::xxh3::hash128
, it's only when going through twox_hash::Xxh3Hash128
.For what it's worth, I can also see this, I think, in valgrind as some reads from uninitialized memory simply when running this (no python, cylib, or anything like that required).
use std::hash::Hasher;
use twox_hash::xxh3::HasherExt;
fn main() {
let seed = 0;
let ss = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
let mut hasher = twox_hash::Xxh3Hash128::with_seed(seed);
hasher.write(ss.as_bytes());
println!("hash a constant of size {} {}", ss.len(), hasher.finish_ext());
}
That... doesn't sound good.
@flier, it sounds like some unsafety has crept in with the xx3 implementation; any thoughts?
I seem to have xxh3 hashes that depend on some uninitialized variable (?) only when compiling into a cdylib. I initially noticed this in a python extension with pyo3, but I've managed to make the following simple reproduction:
Running with
I seem to get different results every time.
If instead I move the contents of the function hash_a_constant to
fn main
and run it as a rust binary, rather than calling the symbol in the .so, then I always get a stable value (295345945357457693424139354068657467622
).For what it's worth, this is on rustc 1.52.1 on x86_64-linux