unix_sysconf throws Illegal seek when glibc-2.26 is used

[despairblue]

Example file:

(* open Core *)

let () =
    print_string "hello world"

Using ocaml@4.04.1 and core@0.9.1 (both installed via opam) compiling this file leads to a binary that prints our hello_world.
But when Core is opened the binary will fail with:

Uncaught exception:
  
  (Unix.Unix_error "Illegal seek" sysconf "")

Raised by primitive operation at file "src/core_unix.ml", line 348, characters 14-29

Using glibc@2.25 everything both works fine.

[aalekseyev]

Interesting. Looks like sysconf can return -1 when the name of the variable is correct, but the value is not available, in which case it does not change errno and you end up with nonsense error message ("Illegal seek" in this case). We should probably detect this situation and return None.

Other than that, max_iovecs should probably be lazy (and optional).

[copy]

Also running into this. Note that even though sysconf(_SC_IOV_MAX) returns -1, IOV_MAX is still available (it's the limit on the compiled system, not the current system, but it might provide a good fallback).

[pzel]

Just another data point: I ran into the same issue with ocaml@4.04.2, core@0.9.1 (via opam) on void linux (glibc 2.26).

Recompiling core with

  let max_iovecs = Array.max_length;;

in core_unix.ml does indeed sweep this under the rug.

[gtrak]

I managed to work around this with a nix-shell on ubuntu 17.10 beta (just introduced glib 2.26 yesterday?).

[cdepillabout]

@gtrak FWIW, I ended up using nix-shell to work around this as well. I'm on Arch Linux. glibc 2.26 was introduced a few weeks ago.

In case it helps anyone else working through Real World OCaml, here are the steps I used getting this work:

1. Install nix. This gives you nix binaries on your path like nix-shell, nix-env, etc.

2. Create a file that looks like the following and name it something like ocaml.nix:

   { pkgs? (import <nixpkgs> {}) }:
   with pkgs;
   
   stdenv.mkDerivation rec {
     name = "ocamlenvironment";
     env = buildEnv { name = name; paths = buildInputs; };
     builder = builtins.toFile "builder.sh" ''
       source $stdenv/setup; ln -s $env $out
     '';
   
     buildInputs =
       (with ocaml-ng.ocamlPackages_4_05; [
         ocaml
         camlp4
       ]) ++ 
       [
         # this is for conf-gmp
         gmp
         # this is for the ocaml compiler
         ncurses
         opam
         # this is for the ssl library
         openssl
         # this is for cryptokit
         zlib
       ];
   }

3. Run nix-shell ocaml.nix.

   This drops you in an environment with the OCaml compiler and opam available. You can use opam to install additional packages like normal. opam switch should tell you that you are using the system compiler.

I also created a question on Stack Overflow about this exact problem before I found this issue.

[Mandragorian]

Is there any update on this issue? I would like to use the core library without any workarounds.

[aalekseyev]

We are working on a fix.

[aalekseyev]

This should be fixed in the next version of core.
The fix is to:

• correctly handle return value of [sysconf]
• default to 1024 if sysconf returns no value for IOV_MAX

[catalin-hritcu]

@aalekseyev Many thanks. When is the next release planned?

[copy]

The fix has been merged, a opam update && opam upgrade resolves this problem for me.

[lorepozo]

This is still broken for me on ocaml-4.06.0 with core-v0.9.2. Same reproduction as ticket description.

[copy]

This is still broken for me on ocaml-4.06.0 with core-v0.9.2. Same reproduction as ticket description.

You're right, I tested a bit hasty. Sorry about the noise.

[xclerc]

For the record, the v0.9.2 was only to released to make core installable from the 4.06.0 switch.

[ghost]

Was it made intentionally to set 4.06.0 as a minimum version? To be correct core v.0.9.2 requires base v.0.9.4, which requires sexplib (>= v0.9.3 & < v0.10) and sexplib v.0.9.3 can be installed only since OCaml 4.06.0. No plans of this fix for 4.05.0 (or even for ocaml-version >= "4.03.0")?

[remy-luisant]

Any chance we could have at least a patch for this one? Seems like this was fixed two weeks ago...

[seliopou]

The fix was committed to master as part of c3761ac, which was about a week ago. You can see the core of the fix in the cstubs here. Following the bindings for unix_sysconf should lead you to the rest of the changes.

An official OPAM release will happen in the next week or two. Until then, pinning core to master, or a specific, hash after c3761ac should get your back up and running.

Closing this, as the issue has been resolved. Check out #99 to track the next OPAM release.