maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Boué (JIRA) <j...@apache.org>
Subject [jira] [Commented] (SUREFIRE-1376) "The forked VM terminated without properly saying goodbye" when running Surefire in a very deep project structure on Windows
Date Mon, 19 Jun 2017 19:43:00 GMT

    [ https://issues.apache.org/jira/browse/SUREFIRE-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054640#comment-16054640
] 

Guillaume Boué commented on SUREFIRE-1376:
------------------------------------------

[~tibor17]

I've detected an issue with this fix: it solves the problem on Oracle JDK 1.8.0_121, but it
doesn't on Oracle JDK 1.7.0_80.

Furthermore, I've tested that changing the launching code from {{java -jar &#92;&#92;?&#92;<...>.jar}}
to {{java -cp <...>.jar main.class}} works with both JDK versions, and without the {{&#92;&#92;?&#92;}}
prefix. It looks like there is a bug with JDK 7 when deriving the main class from the manifest
of a JAR under a too long path. Passing directly {{-cp}} and the main class avoids that, and
the rest of Java code handles the long path just fine. I think commit 59c065f should be reverted,
and replaced with this approach in {{ForkConfiguration}}:

{code:java}
File jarFile = createJar( classPath, providerThatHasMainMethod );
cli.createArg().setValue( "-cp" );
cli.createArg().setValue( jarFile.getAbsolutePath() );
cli.createArg().setValue( providerThatHasMainMethod );
{code}

> "The forked VM terminated without properly saying goodbye" when running Surefire in a
very deep project structure on Windows
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SUREFIRE-1376
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1376
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: Maven Failsafe Plugin, Maven Surefire Plugin
>    Affects Versions: 2.20
>         Environment: Windows
>            Reporter: Guillaume Boué
>            Assignee: Tibor Digana
>             Fix For: 2.20.1
>
>         Attachments: SUREFIRE-1376-prefix.patch
>
>
> When Surefire is ran on a project under a very long path (exceeding Windows' {{MAX_PATH}}),
the invocation fails with
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM terminated
without properly saying goodbye. VM crash or System.exit called?
> {noformat}
> In the generated dumpstream, there is
> {noformat}
> # Created on 2017-05-28T10:17:09.474
> Error: Unable to access jarfile C:\Users\Guillaume\Desktop\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\target\surefire\surefirebooter2512478076549179739.jar
> {noformat}
> The problem is that the path to the JAR file exceeds the maximum path length of 260 characters,
and so it cannot be accessed.
> Prepending the path to the JAR file with {{&#92;&#92;?&#92;}}, [as documented
on MSDN|https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath], makes the
test run again correctly. I've attached a possible patch with this approach (SUREFIRE-1376-prefix.patch,
that also handles UNC pathnames), but perhaps there is a better way to tackle this problem.
> In order to reproduce this, it is possible to create a project under lots of different
subdirectories, something like:
> {noformat}
> └───surefire-longpath-test-with-windows
>     └───surefire-longpath-test-with-windows
>         └───surefire-longpath-test-with-windows
>             └───surefire-longpath-test-with-windows
>                 └───surefire-longpath-test-with-windows
>                     │   pom.xml
>                     │
>                     └───src
>                         └───test
>                             └───java
>                                 └───Test.java
> {noformat}
> As a side-note, this issue is behind the current Jenkins failures on [maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows|https://builds.apache.org/job/maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows/3702/]
when running the ITs on the Assembly Plugin.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message