[Pkg-javascript-devel] Bug#900237: libuv1: FTBFS on hppa: not ok 46 - fs_copyfile

[John David Anglin]

On 2018-06-02 4:35 AM, Dominique Dumont wrote:
> On Sun, 27 May 2018 17:35:40 -0400 John David Anglin<dave.anglin at 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.anglin at bell.net