Bug#900237: libuv1: FTBFS on hppa: not ok 46 - fs_copyfile
On 2018-06-03 10:09 AM, Helge Deller wrote: 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 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 -223UV_ENOTSUP=-252 and EOPNOTSUPP=-223 You are correct. I think I'm getting dyslexic. 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. According to this manpage, the kernel returns EOPNOTSUPP, not ENOTSUP: http://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html So, the test is wrong to check UV_ENOTSUP (ENOTSUP). Thanks, Dave -- John David Anglin dave.ang...@bell.net
Bug#900237: libuv1: FTBFS on hppa: not ok 46 - fs_copyfile
On Saturday, 2 June 2018 17:01:42 CEST you wrote: > 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. ok. I've forwarded the bug upstream [1]. Please follow-up there. All the best [1] https://github.com/libuv/libuv/issues/1862
Bug#900237: libuv1: FTBFS on hppa: not ok 46 - fs_copyfile
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
>> 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 -223UV_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, , 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();
Bug#900237: libuv1: FTBFS on hppa: not ok 46 - fs_copyfile
On 2018-06-02 4:35 AM, Dominique Dumont wrote: On Sun, 27 May 2018 17:35:40 -0400 John David Anglin wrote: The value of r in the failing assertion is -233. If the value is a standard errno, it is ENOBUFS. Gnu error codes [1] mention: Macro: int ENOBUFS “No buffer space available.” The kernel’s buffers for I/O operations are all in use. In GNU, this error is always synonymous with ENOMEM; you may get one or the other from network operations. Macro: int ENOMEM “Cannot allocate memory.” The system cannot allocate more virtual memory because its capacity is full. In my experience, this typically occurs after approximately 1.3 GB are allocated. The amount can vary due fragmentation. I don't think hppa differs significantly from other 32-bit targets in the amount of memory that can be allocated (e.g., mips). 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. Dave -- John David Anglin dave.ang...@bell.net
Bug#900237: libuv1: FTBFS on hppa: not ok 46 - fs_copyfile
On Sun, 27 May 2018 17:35:40 -0400 John David Anglin wrote: > The value of r in the failing assertion is -233. If the value is a standard > errno, it is ENOBUFS. Gnu error codes [1] mention: Macro: int ENOBUFS “No buffer space available.” The kernel’s buffers for I/O operations are all in use. In GNU, this error is always synonymous with ENOMEM; you may get one or the other from network operations. Macro: int ENOMEM “Cannot allocate memory.” The system cannot allocate more virtual memory because its capacity is full. I gues that the hppa machine are too old to test libuv1. I don't see any choice but to remove hppa from the list of supported arches. What do you think ? All the best [1] https://www.gnu.org/software/libc/manual/html_node/Error-Codes.html
Bug#900237: libuv1: FTBFS on hppa: not ok 46 - fs_copyfile
Source: libuv1 Version: 1.20.3-1 Severity: normal Dear Maintainer, Test 46 fails on hppa: not ok 46 - fs_copyfile # exit code 6 # Output from process `fs_copyfile`: # Assertion failed in test/test-fs-copyfile.c on line 182: r == 0 || r == UV_ENOSYS || r == UV_ENOTSUP || r == UV_ENOTTY The value of r in the failing assertion is -233. If the value is a standard errno, it is ENOBUFS. Full build log is here: https://buildd.debian.org/status/fetch.php?pkg=libuv1=hppa=1.20.3-1=1527441587=0 Regards, Dave Anglin -- System Information: Debian Release: buster/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 4.14.44+ (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
