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
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]
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
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
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