Bug 316594

Comment 1 Cyril Jaquier 2010-06-23 09:13:56 EDT

As suggested by Eike, I tried to set several caches to strong references. No success so far.

This bug only appears with [Combined, MEMBranches, JVM, Legacy]. I'm now able to reproduce the bug if I run the test alone.

I also tried to add a few sleeps in the tests but it still fails. So I don't think it's a timing issue.

Comment 2 Cyril Jaquier 2010-06-23 09:14:42 EDT

Created attachment 172501 [details]
testDetachExisting output

Output of BranchingTest.testDetachExisting [Combined, MEMBranches, JVM, Legacy]

Comment 3 Eike Stepper 2010-06-24 14:45:31 EDT

(In reply to comment #1)
> This bug only appears with [Combined, MEMBranches, JVM, Legacy]. I'm now able
> to reproduce the bug if I run the test alone.

Just a note: You can run this test scenario with the launch config named "CDO AllTests (MEM legacy)"

Comment 4 Cyril Jaquier 2010-06-25 03:41:34 EDT

(In reply to comment #3)
> (In reply to comment #1)
> > This bug only appears with [Combined, MEMBranches, JVM, Legacy]. I'm now able
> > to reproduce the bug if I run the test alone.
> 
> Just a note: You can run this test scenario with the launch config named "CDO
> AllTests (MEM legacy)"

No because AllTestsMEMLegacy runs MEM but not MEMBranches.

Comment 5 Cyril Jaquier 2010-06-25 03:43:02 EDT

Created attachment 172717 [details]
Add MEMBranches scenario to AllTestsMEMLegacy

Maybe MEM_AUDIT should be added too. Or is this deprecated?

Comment 6 Eike Stepper 2010-06-25 03:44:12 EDT

(In reply to comment #4)
> > > This bug only appears with [Combined, MEMBranches, JVM, Legacy]. I'm now able
> > > to reproduce the bug if I run the test alone.
> > 
> > Just a note: You can run this test scenario with the launch config named "CDO
> > AllTests (MEM legacy)"
> 
> No because AllTestsMEMLegacy runs MEM but not MEMBranches.

IIRC we wanted to let the legacy tests run with branching mode. Martin, should we fix this in the test suite?

Comment 7 Martin Fluegge 2010-06-27 08:08:09 EDT

Honestly, I can't remember discussing this. But we should definitively test Legacy with branching.

I tried to reproduce the Exception mentionend above but was not successful, neither on MEM nor on MEM_BRANCHES scenario.

Comment 8 Eike Stepper 2010-06-29 04:54:25 EDT

Rebasing all outstanding 3.0 problem reports to version 3.0.1

Comment 9 Eike Stepper 2010-07-02 09:23:50 EDT

Not sure if it is related, but the same exception occurs in a few other tests as well:
https://build.eclipse.org/hudson/job/emf-cdo-integration/532/
https://build.eclipse.org/hudson/job/emf-cdo-integration/534/

Note that in these builds/tests it also occurs in NON-legacy tests ;-(

Comment 10 Martin Fluegge 2010-07-04 14:37:42 EDT

Created attachment 173377 [details]
Test v1

Eike, I'm not sure whether the error of this bugzilla and the ones in the frozen builds are the same, because the stack traces do not match. 

But I noticed that currently Bugzilla_313326_Test fails with the same exception as in the builds. I tried this locally and was first able to reproduce in about 5% of the runs. 

By changing the test a bit (see patch) it becomes always reproducible. I think the meaning of the test logic remains. So it could be a timing issue?

Just a rough guess. Need to look at it in more detail.

Comment 11 Eike Stepper 2010-07-07 07:10:14 EDT

Fixing wrong bug version.

Comment 12 Martin Fluegge 2010-11-20 08:55:55 EST

Renamed bugzilla since it does not only occur in legacy mode.

Comment 13 Martin Fluegge 2011-02-14 16:49:37 EST

I looked at this topic again and after re-enabling the method it turned out that it now fails reproducible in all Branching scenarios. So branching is the problem for this test. And it does not fail with an ObjectNotFoundException but fails on a check (see stack trace). Could anyone please confirm that the ONFE does not occurs anymore?

junit.framework.AssertionFailedError: expected:<2> but was:<1>
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.failNotEquals(Assert.java:283)
	at junit.framework.Assert.assertEquals(Assert.java:64)
	at junit.framework.Assert.assertEquals(Assert.java:195)
	at junit.framework.Assert.assertEquals(Assert.java:201)
	at org.eclipse.emf.cdo.tests.BranchingTest.check(BranchingTest.java:664)
	at org.eclipse.emf.cdo.tests.BranchingTest.testDetachExisting(BranchingTest.java:646)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at junit.framework.TestCase.runTest(TestCase.java:168)
	at org.eclipse.net4j.util.tests.AbstractOMTest.runBare(AbstractOMTest.java:200)
	at org.eclipse.emf.cdo.tests.config.impl.ConfigTest.runBare(ConfigTest.java:467)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at org.eclipse.net4j.util.tests.AbstractOMTest.run(AbstractOMTest.java:246)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at org.eclipse.emf.cdo.tests.config.impl.ConfigTestSuite$TestWrapper.runTest(ConfigTestSuite.java:126)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Comment 14 Eike Stepper 2011-02-14 23:44:52 EST

No failures here or on Hudson.

Comment 15 Martin Fluegge 2011-02-15 02:58:51 EST

The method is renamed to BranchingTest._testDetachExisting(). You need to remove the underscore to make it run ;)

Comment 16 Martin Fluegge 2011-05-21 13:34:47 EDT

Created attachment 196274 [details]
Test v2

After having a closer look to the test I think that this problem is simple a matter of a wrong assumption about the state of the test. 
On the third commit the *OrderDetail* was removed from the resource, so assuming that the resource contains two objects on commitTimeStamp3 seems to be wrong. 
I attached a patch which fixes this.

Comment 17 Eike Stepper 2011-05-23 12:16:18 EDT

Any idea why that could make the test *randomly* fail or pass?

Comment 18 Martin Fluegge 2011-05-23 14:45:49 EDT

> Any idea why that could make the test randomly fail or pass?
Actually not. But I couldn't reproduce the randomness of the failing (oh, that sounds strange). When I started again working on this one it failed every time.

Comment 19 Martin Fluegge 2011-05-23 14:46:05 EDT

Committed revision 7826:
- trunk/plugins/org.eclipse.emf.cdo.tests

Comment 20 Martin Fluegge 2011-05-23 14:46:19 EDT

Committed revision 7826

Comment 21 Martin Fluegge 2011-05-24 01:37:48 EDT

Because this cannot be reproduced I close this one. Please re-open if necessary.

Resolved Fixed.

Comment 22 Eike Stepper 2011-05-24 02:28:16 EDT

Note: It could be that this random problem was the same or similar to the one we've fixed in bug 346477.

Comment 23 Eike Stepper 2011-06-23 04:26:53 EDT

Moving all open problem reports to 4.0

Comment 24 Eike Stepper 2012-09-21 06:49:52 EDT

Closing.