failure in testAssertFailureThreadDump with weme 6.1 / JSR 169

• Key: DERBY-3814
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Myrna van Lunteren
• Reporter: Myrna van Lunteren
• Component/s: Test
• Affects Version/s: 10.5.1.1
• Fix Version/s: 10.5.3.0, 10.6.0.0

Description

suites.All resulted in (1 error and) 2 failures:

1) testAssertFailureThreadDump(org.apache.derbyTesting.unitTests.junit.AssertFailureTest)junit.framework.ComparisonFailure: String not correct. expected:<......> but was:<...
...>
at org.apache.derbyTesting.unitTests.junit.AssertFailureTest.testAssertFailureThreadDump(AssertFailureTest.java:102)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
2) testAssertFailureNoThreadDump(org.apache.derbyTesting.unitTests.junit.AssertFailureTest)junit.framework.ComparisonFailure: String not correct. expected:<......> but was:<...
...>
at org.apache.derbyTesting.unitTests.junit.AssertFailureTest.testAssertFailureNoThreadDump(AssertFailureTest.java:130)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)

Comments

[Myrna van Lunteren]

not sure exactly when this started failing; the nightly tests haven't been finishing before the next cycle kicks off (last good result: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-678612.html.)

[Myrna van Lunteren]

I must've been running with sane jars when I saw this.
There's been good nightly results since, but the test hasn't failed, because it gets skipped with insane jars. (See DERBY-3618).
The test still fails.

[Myrna van Lunteren]

Actually, I can make the same failure happen with sane jars and sun's jdk142.

I think it's because of this characteristic of PrintWriter.println:
 (from the api doc:)
 println() methods use the platform's own notion of line separator rather than the newline character

println is used in this section in org.apache.derby.shared.common.sanity.AssertFailure:
        } catch (NoSuchMethodException e) {
            p.println("(Skipping thread dump because it is not " +
            "supported on JVM 1.4)");
And then the comparison in AssertFailureTest fails on the windows platform because the line separator is different from what's given as expected:
            String expected = "(Skipping thread dump because it is not " +
             "supported on JVM 1.4)\n";
Using \r\n in the expected string makes the assertEquals pass on windows.

A similar check for correct string returned passes for 1.5 and higher because the comparison there is using s.startsWith().

The easiest solution is to trim() s before doing the comparison.

[Myrna van Lunteren]

committed the change with revision 793848.

[Myrna van Lunteren]

backported the fix to 10.5.2.1 with revision 800646.