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