Eio.Path.load loads only first 4gb on big files

[EduardoRFS]

I'm using the Luv backend and when trying to load a file bigger than 4gb's the result string always ends up being the first 4gb's of the file.

[haesbaert]

Can confirm:

$ dune build && EIO_BACKEND=luv ./_build/default/bench/foo.exe
len=4294967296
[0]=A
[2^32 - 1]=A
Fatal error: exception Invalid_argument("index out of bounds")

$ ./_build/default/bench/foo.exe
len=4294967297
[0]=A
[2^32 - 1]=A
[2^32]=B

My first suspicion was not using 64bits off_t, but it seems it is, at some point someone is storing it in 32bit.

[haesbaert]

The bug seems to be internal to libuv:

uv_fs_read:2006
uv__fs_read:473
uv__fs_read:481 result=2147479552 len=2147483648
+got = 2147479552
uv_fs_read:2006
uv__fs_read:473
uv__fs_read:481 result=4096 len=4096
+got = 4096
uv_fs_read:2006
uv__fs_read:473
uv__fs_read:481 result=0 len=0  <--- here libuv is calling read(2) with a buffer of zero length, so it returns 0.

the caller is src/unix/fs.c:uv__fs_read():

      result = read(req->file, req->bufs[0].base, req->bufs[0].len);
      printf("%s:%d result=%zd len=%zd\n", __func__, __LINE__, result, req->bufs[0].len);

[haesbaert]

We're actually passing a 2^32 buffer, somehow it turns into 0, somewhere must be wrapping around, anyway it's late.

uv_fs_read:2006
uv__fs_read:473
uv__fs_read:481 result=4096 len=4096
+got = 4096
+our cstruct len=4294967296 balen=4294967296
uv_fs_read:2006
uv__fs_read:473
uv__fs_read:481 result=0 len=0
+>>EOF<<

10 bucks it's a literal int overflow

[haesbaert]

So the bug seems to be in luv, we pass the correct number, but libuv gets a very likely overflowed int.
I need to learn ctypes to continue.

uv_fs_read:2010 bufs[0] base=0x7f0987ff8010 len = 0

[haesbaert]

Found it:
https://github.com/aantron/luv/blob/0ed668e87ca55d65f4f84422b0dd3381701c71b0/src/helpers.ml#L53

utop # Unsigned.UInt.of_int 4294967296;;
- : Unsigned.uint = <uint 0>

[anmonteiro]

It might be time to start discussing a community fork of luv if we ever want to see that fixed.

[haesbaert]

It might be time to start discussing a community fork of luv if we ever want to see that fixed.

Yes, we also have an unstable ABI with uring (I've hit two kernel bugs the last week). I also don't think luv offers much other than portability with windows, there had been talks about just writing a pure backend that is at least POSIX and windows can eat cake until IOCP is done.

[talex5]

We can work around this in eio_luv quite easily by limiting the amount we ask libuv to read in one go to 2GB. It's unlikely it would do more than that anyway, and the caller will handle it like any other short read.

[haesbaert]

We can work around this in eio_luv quite easily by limiting the amount we ask libuv to read in one go to 2GB. It's unlikely it would do more than that anyway, and the caller will handle it like any other short read.

It's done here: e2f38d3, needs some ironing out and maybe I should pull that out of that PR.

[talex5]

A separate PR would be great!