00:34 <dmbaturin> Anarchos: I'm not a Haiku user but I think it's cool that you are doing that porting work.

00:34 <Anarchos> dmbaturin what annoys me is that errors :

00:34 <Anarchos>

00:35 <Anarchos> List of failed tests:

00:35 <Anarchos> tests/lib-format/mc_pr586_par.ml

00:35 <Anarchos> tests/lib-runtime-events/test_create_cursor_failures.ml

00:35 <Anarchos> tests/lib-unix/unix-socket/recvfrom_unix.ml

00:35 <Anarchos>

00:35 <Anarchos> and sometimes, there is also tests/lib-format/mc_pr586_par2.ml

02:47 <discocaml> <romain.beauxis> I'm still exploring this stacktrace/memory corruption. The underlying value is using `Atomic` and is called a lot. It also turns out that the client is not oberving an issue with a build using ocaml 5 (which is not yet suitable for production really due to excessive memory usage).

02:48 <discocaml> <romain.beauxis> Question: how much do we know that `Atomic` is.. atomic in `4.14.x` in particular w.r.t. the GC? All I'm seeing in the code is:

02:48 <discocaml> <romain.beauxis> ```

02:48 <discocaml> <romain.beauxis> let get r = r.v

02:48 <discocaml> <romain.beauxis> let set r v = r.v <- v

02:48 <discocaml> <romain.beauxis> ```

02:48 <discocaml> <romain.beauxis> I'm having then run a build with this functionality removed to see if the memory corruption still happens but wanted to ask here too.

02:49 <discocaml> <romain.beauxis> (all I'm seeing in the *compiler* code)

12:43 <rustyne> romain.beauxis: I don’t think there’s a problem there if you don’t have C code (in a separate thread for instance) that can mess it up.

12:53 <rustyne> romain.beauxis: I admit that I wonder if the C compiler might be doing something nasty, such as assuming `Field(_on_keyframe,0)` is a constant and not reloading it properly after the acquire_runtime.

12:53 <rustyne> Have you had a look at the assembly by any chance?

13:42 <discocaml> <romain.beauxis> I did some digging. The call to `caml_callback` seems to go straight to assembly so it would not appear in the stack track necessarily I believe.

13:44 <discocaml> <romain.beauxis> I don't think that the values changes from under the C code but the whole application is under a log of GC pressure and does a lot of runtime release/acquisition. I've had issues in other areas of it already with values being agressively collected.

14:11 <discocaml> <contificate> surprised there isn't some kind of like LLVM-based static analzyzer that modifies the Caml headers to emit like useful things, then give approximate warnings for classes of errors - like even just non-interprocedurally, using a value without holding the runtime lock is ohnoitsover behaviour

16:13 <discocaml> <romain.beauxis> Yeah that'd be nice. In my case, the only thing I'm doing is: testing: `_on_keyframe != Val_none`. Given that `Val_none` is `1` I have a hard time seeing this being a problem.

23:01 <cedb> is there a way to capture output from a command launched with Lwt_process without redirecting to a file?