Frustrating Heisenbug with InheritedMethod

[jmaessen]

source:trunk/ProjectFortress/tests/InheritedMethod.fss periodically fails during ant test on a completely clean checkout. Once it has failed it appears to have corrupted the cache and can never be run until ant cleanCache is performed. On a clean cache, fortress InheritedMethod.fss appears to work repeatedly, and allows a subsequent ant testSystem to succeed (or maybe I just got lucky with the Heisenbug that time). I've now tried this so many different ways with so many different serializers that it's reassuring just to know that a clean test on a clean checkout actually can exhibit the failure.

The seed chosen for testSystem when it broke on a clean checkout was FORTRESS_UNITTESTS_SEED=11f720923bb_16. This doesn't seem to be tolerant to my serialization changes; there I get failures more consistently when I turn on the astgen serializers, but stuff still works under the circumstances described above.

Suspicion falls to the repository, but other areas aren't beyond suspicion. I'm frankly mystified by the whole business, especially as the failure is related to stuff that can manifestly be found in the code:

  /Users/jmaessen/PFC-alt/ProjectFortress/tests/InheritedMethod 
 UNEXPECTED exception 
com.sun.fortress.exceptions.ProgramError: Missing type Base
	at com.sun.fortress.exceptions.ProgramError.error(ProgramError.java:104)
	at com.sun.fortress.interpreter.evaluator.BaseEnv.getRootType(BaseEnv.java:431)
	at com.sun.fortress.interpreter.evaluator.BuildEnvironments.forTraitDecl2(BuildEnvironments.java:838)
	at com.sun.fortress.interpreter.evaluator.BuildEnvironments.forTraitDecl(BuildEnvironments.java:795)
	at com.sun.fortress.interpreter.evaluator.BuildEnvironments.forTraitDecl(BuildEnvironments.java:95)
	at com.sun.fortress.nodes.TraitDecl.accept(TraitDecl.java:52)
	at com.sun.fortress.interpreter.evaluator.BuildEnvironments.doDefs(BuildEnvironments.java:173)
	at com.sun.fortress.interpreter.evaluator.BuildTopLevelEnvironments.forComponent(BuildTopLevelEnvironments.java:211)
	at com.sun.fortress.interpreter.evaluator.BuildTopLevelEnvironments.forComponent(BuildTopLevelEnvironments.java:57)
	at com.sun.fortress.nodes.Component.accept(Component.java:49)
	at com.sun.fortress.interpreter.evaluator.BuildEnvironments.visit(BuildEnvironments.java:127)
	at com.sun.fortress.interpreter.env.CUWrapper.initTypes(CUWrapper.java:284)
	at com.sun.fortress.interpreter.Driver.evalComponent(Driver.java:263)
	at com.sun.fortress.interpreter.Driver.runProgramTask(Driver.java:551)
	at com.sun.fortress.interpreter.evaluator.tasks.EvaluatorTask.compute(EvaluatorTask.java:60)
	at jsr166y.RecursiveAction.exec(RecursiveAction.java:147)
	at jsr166y.ForkJoinTask.quietlyExec(ForkJoinTask.java:417)
	at jsr166y.ForkJoinWorkerThread.step(ForkJoinWorkerThread.java:549)
	at jsr166y.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:534)

[dr2chase]

From the department of irreproducibility:

105 runs of

while ant cleanCache testSystem ; do
(cd default_repository; zip -q -9r `isodate`.caches.zip caches);
done ;

cd default_repository; zip -q -9r `isodate`.caches.zip caches

failed to reproduce the bug. I then tried rerunning with the cached zip files to see if it was (as Jan apparently thought possible) a bug in the serialized data.

for i in 2009*zip ; do
echo $i; unzip -qo $i;
if ../bin/fortress ../ProjectFortress/tests/InheritedMethod.fss ; then 
  true;
else
  echo FAIL FAIL FAIL; exit 1;
fi;
done

That didn't fail, either.

It is possible that this was in some way triggered by the balance bug triggered in r3435, if (perhaps) an overloading resolution/unification swallowed the error, mistaking it for a unification failure (this needs checking, and is farfetched, since an eyeball of the stack trace suggests that this occurs before any unifcation).

Also, in the scripts above, "isodate" is:

  date "+%Y-%m-%dT%H:%M:%S"

For more information on ISO(8601) dates:

 http://www.w3.org/TR/NOTE-datetime
 http://en.wikipedia.org/wiki/ISO_8601
 http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/date_and_time_format.htm

 OpenOffice understands ISO8601 dates. At least one popular, non-open spreadsheet program does not.