bugmonotone - Bugs: bug #19517, tests bind to fixed TCP port...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #19517: tests bind to fixed TCP port numbers

Submitted by:  Roland McGrath <roland>
Submitted on:  Thu 05 Apr 2007 08:30:23 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: incorrect behaviorStatus: Fixed
Privacy: PublicAssigned to: Matthew Gregan <kinetik>
Open/Closed: Closed
mtn version --full: 

0.34

Sun 13 May 2007 12:22:24 AM UTC, comment #4:

Bah, that didn't quite fix it. There were two tests using os.time() to seed the PRNG. These are fixed in 29c0149c0786b57a88c4b76e3cfad90571d7b053.

Matthew Gregan <kinetik>
Project MemberIn charge of this item.
Sat 12 May 2007 10:59:19 PM UTC, comment #3:

I ran into this recently as well. It is fixed in 0b7ded5189d26b1c15b070fd801308f8ee791ab8.

We used to have a variant of this problem with the old autotest test suite, but it looks like the problem came back when we switched to the Lua test suite.

The problem was that the PRNG used to generate a port number to listen on was seeded using the current time in seconds. Obviously, for two or more parallel testsuite runs, there's a good chance that some of the tests will end up with the same seed.

The fix exposes a portable variant of getpid() to Lua, and we now use the result of that to seed the PRNG on startup.

Matthew Gregan <kinetik>
Project MemberIn charge of this item.
Thu 05 Apr 2007 07:13:13 PM UTC, comment #2:

The attached file has the failure details from four different make check runs that failed (each while some other make check run or three was going in parallel). If you want the detailed logs from the runs that happened simultaneously (and succeeded), I can probably find those.

Roland McGrath <roland>
Thu 05 Apr 2007 06:34:25 PM UTC, comment #1:

Can you give any examples for which tests? They are supposed to already be doing the random number generation thing you describe.

Nathaniel Smith <njs>
Project Member
Thu 05 Apr 2007 08:30:23 AM UTC, original submission:

Some of the test suite tests bind to fixed TCP port numbers.
This means you cannot run two copies of the test suite on the same machine at the same time. This is especially annoying for build servers like Fedora's where I update builds for three or more distribution versions when there is a new monotone version to import. I naturally kick off the separate builds in parallel, but when two or more land on the same build server, the test suites of all but one fail. As luck would have it, the one winner was not the same one across multiple servers for different architectures, so all of the builds managed to fail (since good builds for one architecture are discarded if other architectures' builds of the same source failed).

An Noy Ing.

A little utility code in the test harnesses could surely make it easy enough to bind a random port for servers and use that in clients for that test.

Roland McGrath <roland>

 

Attached Files
file #12410:  log added by roland (55KiB - application/octet-stream - excerpts of logs from failing test runs (4 pages))

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by kinetik (Posted a comment)
  • -unavailable- added by njs (Posted a comment)
  • -unavailable- added by roland (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 13 May 2007 04:02:26 AM UTCkinetikStatusNone=>Fixed
    Sat 12 May 2007 10:59:19 PM UTCkinetikAssigned toNone=>kinetik
      Open/ClosedOpen=>Closed
    Thu 05 Apr 2007 07:11:03 PM UTCrolandAttached File-=>Added log, #12410

    Back to the top


    Powered by Savane 3.1-cleanup1