Thanks for looking at the code.
The original QA failure was non-termination of the removal process. The
test program either gets that or a null pointer exception from a loop
near the start of the head method in FastList. Which I get seems to be
very sensitive to changes in run conditions. I've been mainly getting
non-termination with the latest test program version.
Either symptom could be due to the same underlying cause, a node that
should be on the list, and either not removed or designated as a "guard"
node, becoming unreachable by following the next chain from the head
pointer.
The loop in the head method follows the chain forward, unlinking
logically removed non-guard nodes, until it either finds a node that has
not been removed or finds a guard node. Every search has its associated
guard node, and guard nodes are not supposed to get unlinked even if
logically removed. The null pointer failure seems to indicate that at
least one node, the guard node for the failing search, that should be
reachable from the head is disconnected so that the search hits a null
next pointer before finding it.
I consider the guard node system fragile and over-complicated, and do
not use it in the new version.
I'll add a more awake write-up of this information to the JIRA ticket
later today.
I've been running with the default VM on my Ubuntu VirtualBox installations:
Java VM: OpenJDK Client VM (19.0-b09 mixed mode, sharing linux-x86 )
I have not done any testing on different VMs, because the existence of
even one widely distributed VM on which it fails is enough. The fact
that a similar test program for the new FastList does not fail suggests
that it is a problem with FastList, not the VM.
Alarmingly, an overnight repeated run of the QA test did not get any
FastList failures, but did get an unrelated NullPointerException from
proxy code called from the test program.
Patricia
On 2/13/2011 2:00 AM, Dan Creswell wrote:
Sorry, should also have asked - what symptoms of failure have you seen so
far? (Didn't see anything in the JIRA ticket or the code to tell me -
getting old, probably blind and missed it).
On 13 February 2011 09:16, Dan Creswell<[email protected]> wrote:
Test program looks fine.
I'd like to know which JDK's you've run the test on so far please?
On 13 February 2011 00:34, Patricia Shanahan<[email protected]> wrote:
I have rerun the RIVER-391 failing test, the enhanced version of
com/sun/jini/test/impl/outrigger/matching/StressTestWithShutdown.td, with
just the fixes for the synchronization idiom in the QA code. It has not yet
failed.
That means that the only evidence I have of failures in the outrigger
FastList is my own test program. I've simplified and stripped down the test
program, and it still fails. It is attached to RIVER-391 as
FastListTest.java
I believe it is showing real problems in FastList, so that I should go
ahead and check in my new version, but I could be mistaken.
I would welcome review of the test program.
Patricia
