9:02 a.m.
[
https://issues.jboss.org/browse/JBTM-1766?page=com.atlassian.jira.plugin....
]
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-cr...
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