Comment 1 Rafael Chaves 2004-06-22 13:11:18 EDT

i200416220800 on IBM 1.4.1 (Windows)

Most tests under org.eclipse.core.tests.resources.regression.AllTests (and any
tests that ran after it) failed with the error below (during tearDown, deleting
MyProject)):

java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match
outer scope rule: P/MyProject
	at org.eclipse.core.internal.runtime.Assert.isLegal(Assert.java(Compiled Code))
	at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:106)
	at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java(Compiled Code))
	at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java(Compiled
Code))
	at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java(Inlined
Compiled Code))
	at
org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java(Compiled
Code))
	at
org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java(Compiled
Code))
	at org.eclipse.core.internal.resources.Resource.delete(Resource.java(Compiled
Code))
	at org.eclipse.core.internal.resources.WorkspaceRoot.delete(WorkspaceRoot.java:43)
	at
org.eclipse.core.tests.harness.EclipseWorkspaceTest.ensureDoesNotExistInWorkspace(EclipseWorkspaceTest.java(Compiled
Code))
	at
org.eclipse.core.tests.harness.EclipseWorkspaceTest.tearDown(EclipseWorkspaceTest.java:971)
	at
org.eclipse.core.tests.resources.regression.Bug_26294.tearDown(Bug_26294.java:481)
	at junit.framework.TestCase.runBare(TestCase.java:130)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305)
	at
org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:30)
	at
org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:26)
	at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:335)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:272)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:128)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:41)
	at java.lang.reflect.Method.invoke(Method.java:371)
	at org.eclipse.core.launcher.Main.basicRun(Main.java:186)
	at org.eclipse.core.launcher.Main.run(Main.java:647)
	at org.eclipse.core.launcher.Main.main(Main.java:631)

Comment 2 Rafael Chaves 2004-06-22 16:25:05 EDT

Actually, I can consistently reproduce the problem above on the mentioned setup.
It always starts to happen on the same point. If I exclude
org.eclipse.core.resources.IResourceTest from the test suite, all tests pass.

Comment 3 DJ Houghton 2004-06-25 15:44:43 EDT

Continued investigation post-3.0.

Comment 4 Rafael Chaves 2004-08-23 10:39:55 EDT

Failed for n20040820. Summary: it seems this test case is affected by a test
case (same test class) that ran before and did not clean up properly.

junit.framework.ComparisonFailure: 2.3 expected:<F...> but was:<Z...>
at
org.eclipse.core.tests.resources.CharsetTest.testMovingProject(CharsetTest.java:344)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:322)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:198)
at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:35)
at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:31)
at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:335)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.eclipse.core.launcher.Main.basicRun(Main.java:183)
at org.eclipse.core.launcher.Main.run(Main.java:644)
at org.eclipse.core.launcher.Main.main(Main.java:628)

Comment 5 Rafael Chaves 2004-08-26 15:14:03 EDT

This one is failing very often in my machine (Sun JDK 1.4.2_03).

testWriteProject(org.eclipse.core.tests.internal.localstore.FileSystemResourceManagerTest)
junit.framework.AssertionFailedError: 2.1
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.assertTrue(Assert.java:20)
	at
org.eclipse.core.tests.internal.localstore.FileSystemResourceManagerTest.testWriteProject(FileSystemResourceManagerTest.java:425)

The assertion fails because after calling ensureDoesNotExistInFileSystem, the
location for the project sometimes still exists. I could verify that not only
the project directory still is there, but the .project file is there as well.
After some debugging, I could verify that this was not a leftover from a
previous test, but something created during the execution of the failing test.
Also, ensureDoesNotExistInFileSystem seems to be able to delete the whole tree,
otherwise it would have printed a warning message to the console, and that did
not happen. So, it seems some background thread ends up causing the project to
write the description out to the disk when it detects the file is gone.

Comment 6 Rafael Chaves 2004-08-26 15:38:41 EDT

Some more info on the problem reported above: the background thread seems to be
a DelayedSnapshotJob, triggered by a SaveManager.snapshotIfNeeded, which is
called by Workspace.endOperation. This guy ends up repairing the project
description file, and this is why the directory/file reappear misteriously just
after being deleted (and also why it is so hard to reproduce).

Comment 7 Rafael Chaves 2004-08-26 17:31:39 EDT

The failure above was fixed by changing the test case to protect itself from the
other threads' interference by wrapping the critical code into a workspace
operation. Something to keep in mind in our tests now that builds and snapshots
can occur at any time.

Comment 8 Rafael Chaves 2004-08-26 17:45:17 EDT

BTW, JohnA fixed it, not me. :)

Comment 9 Rafael Chaves 2004-09-27 10:28:58 EDT

Opened a separate report for a test (CharsetTest) that started to fail on recent
builds, in the hope that it will be more easily reproduced and fixed than these
ones.

Comment 10 Rafael Chaves 2004-09-27 10:29:39 EDT

And the bug number is....     bug 75081.

Comment 11 John Arthorne 2005-01-25 14:11:39 EST

*** This bug has been marked as a duplicate of 51538 ***