interrupt of wait()ing thread isn't triggering InterruptedException - test intwait3

The NSK test runtime/threads/intwait3 has been failing occasionally in the nightlies:

http://gtee.sfbay/gtee/results/MUSTANG/NIGHTLY/VM-MAIN/2007-03-12/RT_Baseline/vm/64BITWIN-AMD64/server/mixed/vm-vm_6.0_server_mixed_64BITWIN-AMD642007-03-12-20-22-33/ResultDir/intwait3/intwait3.log

http://gtee.sfbay/gtee/results/MUSTANG/NIGHTLY/VM-MAIN/2007-02-24/Main_Baseline/vm/64BITWIN-AMD64/server/mixed/vm-vm_6.0_server_mixed_64BITWIN-AMD642007-02-24-20-23-52/ResultDir//intwait3//intwait3.log

Both failures occurred on machine icemaker

The test basically generates 5000 thousand threads, each of which does this.wait() and expects to received an InterruptException. The main thread starts each thread by doing:

t.start();
t.interrupt();

The target thread expects to get an InterruptedException and if not then an error will be reported.

There are two observed failure modes:

1. In the nightly failures, a thread has completed wait() without encountering the InterruptedException.

2. When reproducing the failure on icemaker I also found that sometimes the test will hang. jstack shows that in that case the main thread is waiting doing a join() on the target, while the target is still blocked in this.wait() - indicating that the interruption got lost somewhere.


The test uses wait() in a way that is sensitive to spurious wakeups, but its odd that it suddenly started to fail. Spurious wakeups in the VM have known causes and this scenario does not seem to fit. Spuriosu wakeups would not account for the hang either.

The failure has only been seen on the one Windows 2003 Server machine. Changing the Java code to trace what was happening seemed to prevent the original failure mode from manifesting. Running two instances of the test in parallel seems to allow the hang to be readily reproduced (the test is being run by the shell in a continuous loop until failure).