https://issues.apache.org/bugzilla/show_bug.cgi?id=43586
Gerry Plummer <[EMAIL PROTECTED]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
--- Comment #11 from Gerry Plummer <[EMAIL PROTECTED]> 2008-09-23 06:11:46 PST
---
I have stumbled on what I believe may be another common cause of this "bug".
This can happen if Ant's junit task is run with fork="yes" in default forkmode,
and you pass in a jvmarg element which has an empty string as value.
We have a common Ant framework script used by multiple projects, with
properties driving the specific project's behavior. E.g. our build uses this
fragment:
<jvmarg value="junit.jvmarg.project"/>
<jvmarg value="junit.jvmarg.internal"/>
where the latter is always defined (by the framework) and the former can be
supplied by users. When we split the jvmargs into these two elements, of course
there was a reason, and at the time both properties had values. Subsequent
usages sometimes broke, because the client project did not provide a property
definition of "junit.jvmarg.project" with a non-empty value (the project's
definition being seen first, the framework's definition having the empty string
as default value).
That was a recipe for the issue reported in this bug. The specific Ant/Junit
problem can be seen when running Ant with the -debug option, producing output
like this (---scrubbed---):
[junit] Executing '/usr/java/jdk1.6.0_07/jre/bin/java' with arguments:
[junit] ''
[junit] '-Dcom.foo=NONE
[junit] '-classpath'
[junit] --- classpath elements here ---
[junit] 'org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner'
[junit] --- Test class here ---
[junit] 'filtertrace=true'
[junit] 'haltOnError=false'
[junit] 'haltOnFailure=false'
[junit]
'formatter=org.apache.tools.ant.taskdefs.optional.junit.SummaryJUnitResultFormatter'
[junit] 'showoutput=false'
[junit] 'outputtoformatters=true'
[junit] 'logtestlistenerevents=true'
[junit]
'formatter=org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormatter,/---Test
xml file here ---
[junit]
'crashfile=/---some-path-here---/junitvmwatcher602965515.properties'
[junit] 'propsfile=/---some-path-here---/junit1771756651.properties'
[junit]
[junit] The ' characters around the executable and arguments are
[junit] not part of the command.
Note the empty string on the line immediately after the Executing. That is the
empty string contributed by the first jvmarg element, from the
empty-string-valued "junit.jvmarg.project" property. The line with
"-Dcom.foo=NONE" was contributed by the second jvmarg element, the
"junit.jvmarg.internal" having this (phony) value. The JVM crashed because of
this empty (1st) argument.
If we define a non-empty value for "junit.jvmarg.project" the problem goes away
(the empty line being replaced by something the JVM will swallow, like
"-Djunk=ignore".
The underlying Ant problem (yes I think there is one) is that it doesn't check
for empty arguments like this before running the JVM. I think it should do so,
because the consequences are so pernicious and difficult to debug, and their
seem to be no benefit. Specifically, I suggest the CommandlineJava class
(instances of which are used by JUnitTask.executeAsForked() to represent the
forked JVM command to run) should, somewhere in the conversion of the
constituents of the command to a List of command elements (Strings), if there
is an empty string it should perhaps be skipped over. Or, more narrowly, te
Java13CommandLauncher inner class could deal with the issue since it's that
launcher that seems to be the last place to do so.
Furthermore, it seems that some improved error handling could be used here.
There are no failures detected by the Execute nor JUnitTask classes in running
the JVM which summarily exits. But (as is seen at the top of this bug) neither
is there valid information about a JVM "crash" in the
junitvmwatcher*.properties file (which doesn't exist). We simply see an
exception from Ant with no hint to the uninitiated (and a lot of debugging for
those who may be).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
