make check hangs in network-stream-tests.el

make check hangs in network-stream-tests.el

[Stephen Berman]

When I run `make check' it sometimes hangs in network-stream-tests.el.
I've left it alone for as much as 10-15 minutes and then aborted.  Today
it happened again, so after aborting I ran ert interactively on
network-stream-tests.el and got one successful run of all tests but also
a hang; here are the results in the latter case:

   Selector: t
   Passed:  2
   Failed:  0
   Skipped: 0
   Total:   2/10
   
   Started at:   2017-07-19 16:17:02+0200
   Aborted.
   Aborted at:   2017-07-19 16:22:24+0200
   
   ..Q-------
   
   . connect-to-tls-ipv4-nowait
       passed
   
   . connect-to-tls-ipv4-wait
       passed
   
   Q connect-to-tls-ipv6-nowait
       (quit)


This is what *Messages* contains:

   gnutls-serv: HTTP Server listening on IPv4 0.0.0.0 port 44331...done
   HTTP Server listening on IPv6 :: port 44331...done
   
   gnutls-serv: HTTP Server listening on IPv4 0.0.0.0 port 44332...done
   HTTP Server listening on IPv6 :: port 44332...done
   
   gnutls-serv: HTTP Server listening on IPv4 0.0.0.0 port 44333...bind() failed: Address already in use
   HTTP Server listening on IPv6 :: port 44333...bind() failed: Address already in use
   
   Abort testing? (y or n) y
   Aborted: Ran 10 tests, 2 results were as expected

During this test run and during make check, I had AFAIK no network
problems, and again, sometimes the tests complete successfully.  So
what's going on?

When this hang has happened, the only way I found to get `make check' to
complete was to temporarily remove network-stream-tests.el and
network-stream-tests.elc.  Is there a better alternative?

Steve Berman

Re: make check hangs in network-stream-tests.el

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

>    gnutls-serv: HTTP Server listening on IPv4 0.0.0.0 port 44333...bind() failed: Address already in use
>    HTTP Server listening on IPv6 :: port 44333...bind() failed: Address already in use

I've noticed that the tests aren't able to reliably kill off the
gnutls-cli commands they spawn, but I haven't been able to figure out
why...

Perhaps they should do a `signal-process' -9 to the processes after use
to make sure?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no