RFR 8008223: java/net/BindException/Test.java fails rarely

[Alan Bateman]

On 14/02/2013 14:43, Chris Hegarty wrote:
> Webrev:
>   http://cr.openjdk.java.net/~chegar/8008223/webrev.00/webrev/
>
> This test has been around a long time, and rarely fails, but has had 
> several bugs closed as 'not reproducible' marked against it.
>
> The test tries to verify that a BindException is thrown, or not 
> thrown, in the appropriate circumstances. It does this by 
> creating/binding a first socket to a specific socket address, then 
> attempting to bind a second socket to possibly the same address. If 
> the second socket attempts to bind to the same address as the first 
> socket, then a BindException is expected to be thrown.
>
> The problem appears to be an issue with the test itself. A local 
> variable holds a reference to the first socket. This local variable is 
> never accessed again within its scope (or elsewhere), therefore 
> becomes instantly unreachable and eligible for collection by the GC. 
> The second socket, if binding with the same address, is expected to 
> throw BindException, but the first socket is no longer guaranteed to 
> be live and therefore the address is not guaranteed to be unbindable.
>
> I managed to reproduce the failure above, relatively consistently, by 
> inserting 'System.runFinalization(); System.gc();' between the 
> creation/binding of the first socket and the binding of the second 
> one. This gives weight to the above analysis.
>
> The solution is to simply add some trivial statement that references 
> the first socket, after the second one is bound. This will ensure that 
> the first socket remains reachable until after the second socket 
> attempts to bind.
>
> -Chris.
I guess this is assuming that their the tests are run with -ea or that 
the presence of the assert will keep the reference alive. Would it be 
better to just have a finally block that closes the sockets (from a 
brief look it doesn't appear that this test cleans up anyway).

-Alan