Re: perl 5.20 test failures

[Samuel Thibault]

Svante Signell, le Mon 18 Aug 2014 11:31:16 +0200, a écrit :
> Running the t/io/socket test manually reveals:
> ok 1 - close the socket
> ok 2 - make a tcp socket
> ok 3 - bind works
> ok 4 - getsockname() on bound socket
> # port 41258
> ok 5 - listen() works
> ok 6 - make accept tcp socket
> ok 7 - accept() works
> ok 8 - close server socket in child
> ok 9 - make child tcp socket
> ok 10 - connect() works
> not ok 11 - peer from recv() should be empty or the remote name
> ok 12 - check we received the data
> ok 13 - shutdown() works
> 1..13
> 
> So something is fishy with recv() as implemented.

The test seems fishy to me: it is making sure that the name as returned
by recv is *exactly* the same as what the server socket is bound to,
which is 0.0.0.0:some_port but I would expect recv to return the actual
IP address used in the socket, not 0.0.0.0.  It happens that Linux
doesn't return anything at all so it goes fine there, but that's not a
reason.  The test should most probably be discussed with upstream.

> Thread creation failed: pthread_create returned 1073741859 at (eval
> 1470) line 3.
> Thread creation failed: pthread_create returned 1073741859 at (eval 1473) 
> line 3.
> t/re/regexp_qr_embed_thr ...................................... FAILED at 
> test 258
> 
> The t/re/regexp_qr_embed_thr return code 1073741859 is
> #define EAGAIN          _HURD_ERRNO (35)/* Resource temporarily unavailable */
> 
> Any ideas how to track down this problem further?

rgrep EAGAIN in libpthread/, you'll see that it happens when
pthread_create runs out of memory or ports. You could put printfs there
to make sure which case is happening. Perhaps perl is simply allocating
a huge lot of threads, or threads with extremely big stacks.

Samuel