[GRADLE-1511] Gradle tests task hangs, when test throws a specific exception. Created: 04/May/11 Updated: 25/Nov/13 Resolved: 25/Nov/13 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | 1.0-milestone-3 |
Fix Version/s: | 1.10-rc-1 |
Type: | Bug | ||
Reporter: | Alexander Kitaev | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 4 |
Attachments: | test-autonomous.zip test.zip |
Description |
JUnit 3 test of a form: public void testSimple() throws Exception { throw new SVNException(SVNErrorMessage.create(null)) }Makes Gradle hangs forever. Same test run from within Eclipse fails as expected. It looks like the problem is caused by call to SVNErrorMessage.create(...) - when this call is replaced with 'null' test fails as expected. There is nothing special in SVNErrorMessage.create(...), however. Gradle only hangs if exception is thrown, not if it is merely created. Attached is minimal test project that hangs when running "gradlew test". |
Comments |
Comment by Alexander Kitaev [ 04/May/11 ] |
Test project with no external dependencies, except for junit 3.8.2. |
Comment by Alexander Kitaev [ 04/May/11 ] |
I've managed to create another test project, with no external dependencies but junit 3.8.2. The problem is reproducible when exception thrown by JUnit (or any of the objects it references) implements custom serialization with writeObject/readObject methods. If there is such an object in the serialized objects graph, then Gradle test task hangs. |
Comment by Alexander Kitaev [ 04/May/11 ] |
Another thing I've tested is use of readResolve() and writeReplace() methods. public class E extends Exception { private static final long serialVersionUID = 1000L; private static final E SINGLETON = new E("message of a singleton"); public E(String m) { super(m); } protected Object writeReplace() throws ObjectStreamException { return SINGLETON; } protected Object readResolve() throws ObjectStreamException { return SINGLETON; } } does not have any effect. Test fails as expected (does not hang), but nowhere in the output there is a "singleton" message. This is fine, but looks strange, as I would expect SINGLETON exception instance to be used in report output, not the original one. |
Comment by Strong Liu [ 31/Aug/11 ] |
it seems we also run into this issue..... |