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);
