On 02.06.2018 17:01, John David Anglin wrote: > On 2018-06-02 4:35 AM, Dominique Dumont wrote: >> On Sun, 27 May 2018 17:35:40 -0400 John David Anglin<dave.ang...@bell.net> >> wrote: >>> The value of r in the failing assertion is -233. If the value is a standard >>> errno, it is ENOBUFS.
No. The value of r in the failing assertion is -223, which is -EOPNOTSUPP. # r is -223 UV_ENOTSUP=-252 and EOPNOTSUPP=-223 > The test used to pass with 1.18.0, so the problem appears to be a regression > in libuv1. I would > guess that the failure was introduced by the following change: > https://github.com/libuv/libuv/commit/3ae88200d6f52ea7b3d8ff9b8164adde65f6c43a > > The failure line corresponds to this addition. > > The change mentions that an error will be returned if the platform doesn't > support copy-on-write. > I tend to think there's an issue with the error codes either in the kernel or > libuv1. I doubt we are > actually running out of memory. The problem is, that on parisc ENOTSUP and EOPNOTSUPP have different values, which breaks the checks. Other arches, e.g. x86-64 seem to have the same value for both, so there the check doesn't break. test-fs-copyfile.c checks for UV_ENOTSUP (which is ENOTSUP), while in src/unix/fs.c is checked against "errno != EOPNOTSUPP". This needs to be fixed in libuv1. The attached patch is just a workaround. Helge
diff -up ./test/test-fs-copyfile.c.bak ./test/test-fs-copyfile.c --- ./test/test-fs-copyfile.c.bak 2018-06-03 15:35:58.670414404 +0200 +++ ./test/test-fs-copyfile.c 2018-06-03 16:07:44.681343894 +0200 @@ -180,7 +180,7 @@ TEST_IMPL(fs_copyfile) { r = uv_fs_copyfile(NULL, &req, fixture, dst, UV_FS_COPYFILE_FICLONE_FORCE, NULL); fprintf(stderr, "r is now %d\n",r ); - ASSERT(r == 0 || r == UV_ENOSYS || r == UV_ENOTSUP || r == UV_ENOTTY); + ASSERT(r == 0 || r == UV_ENOSYS || r == UV_ENOTSUP || r == -EOPNOTSUPP || r == UV_ENOTTY); if (r == 0) handle_result(&req);