My favorites | Sign in
v8
Project Home Downloads Wiki Issues Source Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 945: Tests using Socket cannot be run in parallel
9 people starred this issue and may be notified of changes. Back to list
 
Project Member Reported by ricow@chromium.org, Nov 24, 2010
Running the cctests on the arm slave makes socket connection checks fail in cctest/test-debug and cctest/test-socket.


Path: cctest/test-debug/DebuggerAgentProtocolOverflowHeader
--- stderr ---
#
# Fatal error in test/cctest/test-debug.cc, line 5814
# CHECK(ok) failed
#
Command: obj/test/release/cctest test-debug/DebuggerAgentProtocolOverflowHeader --testing_serialization_file=obj/test/release/serdes_DebuggerAgentProtocolOverflowHeader
=== release test-sockets Socket ===
Path: cctest/test-sockets/Socket
--- stderr ---
#
# Fatal error in test/cctest/test-sockets.cc, line 99
# CHECK(ok) failed
#
Command: obj/test/release/cctest test-sockets/Socket --testing_serialization_file=obj/test/release/serdes_Socket


I will disable the tests in the status file and point to this bug.

I am assigning this to you Erik, but I will do a trial run on my local arm machine to make sure this is not buildbot related (if it is I will steal the bug back)
Jun 10, 2011
Project Member #1 mikhail.naganov
 Issue 1450  has been merged into this issue.
Cc: sgjesse@chromium.org
Jun 8, 2012
Project Member #2 jkummerow@chromium.org
This is not ARM specific at all. All tests that use Sockets (currently test-socket/Socket, test-debug/DebuggerAgent, and test-debug/DebuggerAgentProtocolOverflowHeader) hard-code the port that they want to open a Socket on. This fails due to the port being in use whenever the test runner script decides to run two or more of the VARIANT_FLAGS versions (e.g. "--nocrankshaft" and "--stress-opt --always-opt") of the same test at the same time.

The proper fix would be to use ephemeral ports, i.e. let the OS pick a random available port. However, our Socket objects don't currently provide a means to retrieve the port that was chosen, which the tests must know in order to connect to it.

I'm actually surprised that we don't see these tests fail more often on ia32/x64. The failures are easily reproduced by running:
$ tools/test-wrapper-gypbuild.py --arch-and-mode=ia32.release -j3 cctest/test-sockets/Socket
(note the -j3; with -j1 all tests pass fine).
Summary: Tests using Socket cannot be run in parallel
Sep 30, 2012
Project Member #3 jkummerow@chromium.org
(No comment was entered for this change.)
Status: Assigned
Owner: jkummerow@chromium.org
Cc: erik.corry
Sep 30, 2012
Project Member #4 sgjesse@chromium.org
This should be a matter of using port 0 when initiating the listen. The folloginc code (from Dart) can be used to get the port chosen afterwards:

intptr_t Socket::GetPort(intptr_t fd) {
  ASSERT(fd >= 0);
  struct sockaddr_in socket_address;
  socklen_t size = sizeof(socket_address);
  if (TEMP_FAILURE_RETRY(
          getsockname(fd,
                      reinterpret_cast<struct sockaddr *>(&socket_address),
                      &size))) {
    fprintf(stderr, "Error getsockname: %s\n", strerror(errno));
    return 0;
  }
  return ntohs(socket_address.sin_port);
}

Oct 1, 2012
Project Member #5 jkummerow@chromium.org
@#4: Thanks for the hint. 

I've landed a quick fix for the immediate issues we were seeing in https://code.google.com/p/v8/source/detail?r=12636 .

I'm leaving this bug open to indicate that long-term we should probably invest the time to do actual flexible choice of ports.
Status: Accepted
Labels: -Type-Bug -Priority-Medium Type-FeatureRequest Priority-Low
Oct 1, 2012
Project Member #6 mstarzinger@chromium.org
(No comment was entered for this change.)
Cc: mstarzinger@chromium.org
Sign in to add a comment

Powered by Google Project Hosting