[jbossts-issues] [JBoss JIRA] (JBTM-1766) STM test failure with emma: Failed tests: testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>

[Tom Jenkinson (JIRA)]

    [ https://issues.jboss.org/browse/JBTM-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780560#comment-12780560 ] 

Tom Jenkinson commented on JBTM-1766:
-------------------------------------

OK, I think I have this one isolated a little in the debugger. Emma (I presume) is modifying the bytecode of the AtomicInteger class to add a field:
private static final boolean[][] org.jboss.stm.internal.types.AtomicIntegerImpl.$VRc

Line 316 of org.jboss.stm.internal.proxy.LockManagerProxy therefore returns false and cascades a decision which makes the LockManagerProxy think it has a conflict.

Is emma wrong to modify the bytecode (a relevant search shows VRc is added by EMMA: http://stackoverflow.com/questions/7389329/why-would-the-java-compiler-create-a-serialversionuid-synthetic-field)? I suspect other frameworks could do similar things with bytecode?

Is STM wrong to assume all state by default? Maybe the user should have to annotate state to save, rather than state not to save?

Is STM wrong to assume a conflict?

Why is it only this test that fails? What about AtomicArrayUnitTest, that one seems to work? I did a quick run of this in the debugger and freeState is called during the second call to set(). I haven't debugged that further to understand if that could be an issue too.

To run this in the debugger, make sure you have the following paths in your debugger:
1. The processed emma byte code must be first in the path so your IDE compiled files will be second. It will be in STM/target/generated-classes/emma/
2. The emma jar from ext/emma.jar
                
> STM test failure with emma: Failed tests:   testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest): expected:<1> but was:<0>
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-1766
>                 URL: https://issues.jboss.org/browse/JBTM-1766
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: STM, Testing
>            Reporter: Tom Jenkinson
>            Assignee: Mark Little
>            Priority: Minor
>             Fix For: 5.0.0.M4
>
>         Attachments: org.jboss.stm.types.AtomicIntegerUnitTest-output (emma off).txt, org.jboss.stm.types.AtomicIntegerUnitTest-output (emma on).txt
>
>
> Most tests run OK, just this one:
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.548 sec <<< FAILURE!
> testTransaction(org.jboss.stm.types.AtomicIntegerUnitTest)  Time elapsed: 0.328 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> 	at junit.framework.Assert.fail(Assert.java:50)
> 	at junit.framework.Assert.failNotEquals(Assert.java:287)
> 	at junit.framework.Assert.assertEquals(Assert.java:67)
> 	at junit.framework.Assert.assertEquals(Assert.java:199)
> 	at junit.framework.Assert.assertEquals(Assert.java:205)
> 	at org.jboss.stm.types.AtomicIntegerUnitTest.testTransaction(AtomicIntegerUnitTest.java:81)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at junit.framework.TestCase.runTest(TestCase.java:168)
> 	at junit.framework.TestCase.runBare(TestCase.java:134)
> 	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 junit.framework.TestSuite.runTest(TestSuite.java:243)
> 	at junit.framework.TestSuite.run(TestSuite.java:238)
> 	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> 	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Could it be caused by emma altering the bytecode (which it has to do)?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira