You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I've been using the LXM.Pure interface and have encountered some strange/erroneous behavior (described in detail here).
Basically, the sequence of random values produced by the PRNG is sometimes incorrect, and this happens when the GC runs a minor collection. After some experimentation, I managed to fix the example linked above in my local environment by changing pringo_LXM_copy and pringo_LXM_init_unboxed from
CAMLprimvaluepringo_LXM_copy(valuev)
{
valueres=caml_alloc_small(Wsizeof(structLXM_state), Abstract_tag);
memcpy(LXM_val(res), LXM_val(v), sizeof(structLXM_state));
returnres;
}
CAMLprimvaluepringo_LXM_init_unboxed(uint64_ti1, uint64_ti2,
uint64_ti3, uint64_ti4)
{
valuev=caml_alloc_small(Wsizeof(structLXM_state), Abstract_tag);
structLXM_state*st=LXM_val(v);
st->a=i1 | 1; /* must be odd */st->x[0] =i2!=0 ? i2 : 1; /* must be nonzero */st->x[1] =i3!=0 ? i3 : 2; /* must be nonzero */st->s=i4;
returnv;
}
to
CAMLprimvaluepringo_LXM_copy(valuev)
{
CAMLparam1(v);
valueres=caml_alloc_small(Wsizeof(structLXM_state), Abstract_tag);
memcpy(LXM_val(res), LXM_val(v), sizeof(structLXM_state));
CAMLreturn(res);
}
CAMLprimvaluepringo_LXM_init_unboxed(uint64_ti1, uint64_ti2,
uint64_ti3, uint64_ti4)
{
CAMLparam0();
CAMLlocal1(v);
v=caml_alloc_small(Wsizeof(structLXM_state), Abstract_tag);
structLXM_state*st=LXM_val(v);
st->a=i1 | 1; /* must be odd */st->x[0] =i2!=0 ? i2 : 1; /* must be nonzero */st->x[1] =i3!=0 ? i3 : 2; /* must be nonzero */st->s=i4;
CAMLreturn(v);
}
I don't fully understand what the problem is, but it seems that maybe the original versions of these functions do not properly register the objects they create with the GC/runtime, so those objects end up getting garbled after the GC runs (perhaps being written over by subsequent allocations?).
I also noticed that the OCaml stdlib Random module uses the same LXM implementation, but it does all of its allocations on the OCaml side so I don't think it should suffer from this problem.
Side note: setting OCAMLRUNPARAM='v=0x02' to print minor collection messages seems to not work on OCaml 5.1.1... I don't know if I'm doing something wrong or if that's a bug that should be reported on the main OCaml repo.
-- Alex
The text was updated successfully, but these errors were encountered:
Hi, I've been using the
LXM.Pure
interface and have encountered some strange/erroneous behavior (described in detail here).Basically, the sequence of random values produced by the PRNG is sometimes incorrect, and this happens when the GC runs a minor collection. After some experimentation, I managed to fix the example linked above in my local environment by changing
pringo_LXM_copy
andpringo_LXM_init_unboxed
fromto
I don't fully understand what the problem is, but it seems that maybe the original versions of these functions do not properly register the objects they create with the GC/runtime, so those objects end up getting garbled after the GC runs (perhaps being written over by subsequent allocations?).
I also noticed that the OCaml stdlib Random module uses the same LXM implementation, but it does all of its allocations on the OCaml side so I don't think it should suffer from this problem.
Side note: setting
OCAMLRUNPARAM='v=0x02'
to print minor collection messages seems to not work on OCaml 5.1.1... I don't know if I'm doing something wrong or if that's a bug that should be reported on the main OCaml repo.-- Alex
The text was updated successfully, but these errors were encountered: