Update to openjdk-8 8u181-b13-1ubuntu0.18.04.1 and openjdk-lts 10.0.2+13-1ubuntu0.18.04.3 breaks Maven builds

[Jeroen Hoek]

Today both the OpenJDK 8 and 11 packages were updated. In the case of OpenJDK 8 (openjdk-8 in Xenial, Bionic, Cosmic, and Disco):

openjdk-8-jdk: 8u181-b13-0ubuntu0.18.04.1 → 8u181-b13-1ubuntu0.18.04.1

OpenJDK 10 (openjdk-lts in Bionic):

openjdk-11-jdk: 10.0.2+13-1ubuntu0.18.04.2 → 10.0.2+13-1ubuntu0.18.04.3

After this update all my local Maven builds fail with a crashed VM. From the console output it looks like one of the prerequisites of JaCoCo (Java code coverage tool) is no longer met, but I haven't been able to figure out what the root cause is.

This problem occurs with both OpenJDK 8 and 10.

Reproduction:

This is one of our projects: https://github.com/LableOrg/java-nicerxvi

Clone the project, and call `mvn clean install`. For me it now fails to build (output attached).

When I downgrade to 8u162-b12-1 everything works again.

[Jeroen Hoek (mail-jeroenhoek)]

Found the root cause: the JaCoCo plugin in my builds needed updating to a more recent version. If anyone lights upon this problem; OpenJDK 8u181-b13-1ubuntu0.18.04.1 and newer break older JaCoCo releases. The newer versions of this tool do work with these and newer JDK releases up to and including 11.

[Jeroen Hoek (mail-jeroenhoek)]

Triage: I think this issue can be closed, although I don't quite understand why a seemingly minor patch in JDK 8 should break tools in this way.

[Viktor (viktorgunnarson)]

I have the same issue and I use the latest version of JaCoCo.

It worked with the previous Java version (8u181-b13-0ubuntu0.18.04.1).

Stacktrace:

[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:671)
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:278)
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:244)
[ERROR] at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1194)
[ERROR] at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1022)
[ERROR] at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:868)
[ERROR] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
[ERROR] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
[ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:955)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

[Jeroen Hoek (mail-jeroenhoek)]

After some more testing and frustration I've found that after updating JaCoCo to 0.8.2 the newest OpenJDK 11 build works, as does the OpenJDK 10 provided by Ubuntu.

The OpenJDK 8 version now provided by Ubuntu doesn't.

[Jeroen Hoek (mail-jeroenhoek)]

So this probably not a bug for the OpenJDK 11 package, but it is for the OpenJDK 8 package. No version of JaCoCo seems to work with the version released today.

Viktor: Does your build work in OpenJDK 11?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Viktor (viktorgunnarson)]

No, I have the exact same issue with openjdk-11-jre.

$ mvn --version
Apache Maven 3.5.2
Maven home: /usr/share/maven
Java version: 10.0.2, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-38-generic", arch: "amd64", family: "unix"

$ java -version
openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.3)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.3, mixed mode)

[Gary Howard (arkessa-gary)]

I can confirm that our builds are broken with any jacoco version for openjdk-8.
The only quick solution for us is to downgrade to an earlier version of openjdk-8 - very annoying.

[Jeroen Hoek (mail-jeroenhoek)]

I've had to disable JaCoCo, and set the <forkCount> of the Surefire-plugin to 0 to get the mini-project 'NiceXVI' linked above to build under this OpenJDK 8 version. So it looks like it is not just JaCoCo.

OpenJDK 11 works after updating JaCoCo though.

Viktor: I have the set $JAVA_HOME in order for Maven to use a different JDK, regardless of the version of java available in the shell. Are you sure you are running the build with javac 10/11?

[Viktor (viktorgunnarson)]

Jeroen: I believe it is using javac 10/11. If I run maven with -X it prints the version info in the beginning and that points to the same paths as below.

$ javac -version
javac 10.0.2

$ java -version
openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.3)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.3, mixed mode)

$ mvn --version
Apache Maven 3.5.2
Maven home: /usr/share/maven
Java version: 10.0.2, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-38-generic", arch: "amd64", family: "unix"

[Jeroen Hoek (mail-jeroenhoek)]

Viktor: Ah, OK, thanks for checking. Interesting that your builds fail in OpenJDK 11 as well as 8, but mine only in this updated OpenJDK 8.

[Gary Howard (arkessa-gary)]

Downgrading openjdk-8 has proven problematic but forcing surefire <forkCount> to zero appears to avoid the problem.

[Martijn (martijn.niji)]

Hey there,

There is a simple but severe bug which has been fixed in Debian OpenJDK packages: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925

This causes a huge number of builds to fail. I believe its connected to / causing this issue as well.

Any chance of getting the upstream patch included in Ubuntu Xenial? The problem was introduced in our environment as a security patch last night... if we can get this fixed tonight, that would be great! :)

[Thorsten Glaser (mirabilos)]

Hi Martijn,

this has not been fixed in Debian, it affects openjdk-8 and openjdk-10 there.

As far as has been analysed to date, this is caused by a new, stricter, JAR check that went from OpenJDK to Debian/*buntu’s Java 10 and 8 (but not Debian’s Java 11), missing that the new check should be disabled by default (probably “for now”).

See also: https://issues.apache.org/jira/browse/SUREFIRE-1588

There, we’re trying to get the maven-surefire-plugin working with the new stricter check. It only hits Debian/*buntu for now, but given that the new check exists upstream (even if disabled for now), it’ll eventually hit everyone.

[timeless (timeless)]

I think I have a Jenkins build system that has hit this error twice. Once involving git polling (okhttp), and once involving svn checkouts.

If I understand @mirabilos's comment from Nov 2 correctly, people are claiming that any software that breaks due to this change is by definition broken and should be fixed. That at best Ubuntu/Debian may be willing to temporarily unbreak such software, but the working assumption is that eventually that temporary reprieve would be revoked.

If I'm right, could someone please help identify which software in this stack trace is doing something "wrong" per the new definition?

From my read of the stack, org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createSSLSocket calls sun.security.ssl.SSLSocketImpl.startHandshake which then spends a large number of frames within sun.security.ssl until it eventually can't access sun.security.ssl.SSLSessionImpl.<init>(Lsun/security/ssl/ProtocolVersion;Lsun/security/ssl/CipherSuite;Ljava/util/Collection;Lsun/security/ssl/SessionId;Ljava/lang/String;IZ)V

Naïvely, I'd blame the maintainers of sun.security.ssl. If I'm not mistaken, I believe that sun.security.ssl is also part of the jdk/jre packages.

[Tiago Stürmer Daitx (tdaitx)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I have updated the status of the bug to reflect the affected Ubuntu releases for both openjdk-8 (Xenial, Bionic, Cosmic, and Disco) and openjdk-10 (Bionic). New packages are under test and will be released soon by the security team with a fix for this bug.

[Sadi Yumuşak (sa-yu)]

Someboy marked my bug report as a duplicate of this bug report.
I don't know all those technical details, maybe they lead to the same, but I'm affected in a different way:

When I updated the openjdk-8 package from 8u181-b12-0ubuntu0.18.04.1 to 8u181-b13-1ubuntu0.18.04.1, I was no longer able to open any file in LibreOffice (Version: 6.0.6.2 Build ID: 1:6.0.6-0ubuntu0.18.04.1).
The same happens if I also install and select the openjdk-11 package in LibreOffice.

[Launchpad Janitor (janitor)]

This bug was fixed in the package openjdk-lts - 10.0.2+13-1ubuntu0.18.04.4

---------------
openjdk-lts (10.0.2+13-1ubuntu0.18.04.4) bionic-security; urgency=medium

  * debian/patches/sec-webrev-11.0.1-b21-S8211731.patch: apply missing
    patch from the security update. (LP: #1800792)

 -- Tiago Stürmer Daitx <email address hidden> Tue, 13 Nov 2018 12:53:39 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package openjdk-8 - 8u191-b12-0ubuntu0.18.04.1

---------------
openjdk-8 (8u191-b12-0ubuntu0.18.04.1) bionic-security; urgency=medium

  * Backport from Cosmic.

 -- Tiago Stürmer Daitx <email address hidden> Tue, 20 Nov 2018 01:07:58 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package openjdk-8 - 8u191-b12-0ubuntu0.16.04.1

---------------
openjdk-8 (8u191-b12-0ubuntu0.16.04.1) xenial-security; urgency=medium

  * Backport from Cosmic.

 -- Tiago Stürmer Daitx <email address hidden> Tue, 20 Nov 2018 01:07:58 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package openjdk-8 - 8u191-b12-0ubuntu0.18.10.1

---------------
openjdk-8 (8u191-b12-0ubuntu0.18.10.1) cosmic-security; urgency=medium

  * Update to 8u191-b12. (Closes: #911925, LP: #1800792)
  * debian/excludelist.jdk.jtx: no longer needed, using ProblemsList.txt
    from upstream now.
  * debian/excludelist.langtools.jtx: upstream testing does not use any
    exclusion list.
  * debian/patches/sec-webrev-8u191-b12*: removed, applied upstream.
  * debian/patches/jdk-8132985-backport-double-free.patch,
    debian/patches/jdk-8139803-backport-warning.patch: fix crash in
    freetypescaler due to double free, thanks to Heikki Aitakangas for
    the report and patches. (Closes: #911847)
  * debian/rules:
    - tar and save JTreport directory.
    - run the same limited set of tests as upstream does.
    - call the same testsuites scripts used for autopkgtest.
    - reenable jdk testsuite.
    - simplified and moved xvfb logic into check-jdk rule.
    - removed jtreg and xvfb build dependency logic and moved the bdeps
      into debian/control.in.
    - added rules to generate autopkgtest scripts from templates.
  * updated dep8 tests:
    - debian/test/control: run hotspot, langtools, and jdk testsuites.
    - debian/tests/hotspot, debian/tests/jdk, debian/tests/langtools:
      add scripts for each testsuite to be run.
    - debian/tests/jtreg-autopkgtest.sh: template to generate the jtreg
      script used by the autopkgtest tests.
    - debian/tests/jtdiff-autopkgtest.sh: used by the scripts to report
      any differences between the autopkgtest and the tests results
      generated during the openjdk package build.
    - debian/tests/jtreg-autopkgtest.sh: used by the scripts to run jtreg
      and put the resulting artifacts in the right places.
    - debian/tests/valid-tests: removed, no longer needed.

 -- Tiago Stürmer Daitx <email address hidden> Mon, 19 Nov 2018 11:02:46 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package openjdk-8 - 8u191-b12-2

---------------
openjdk-8 (8u191-b12-2) unstable; urgency=high

  * Upload to unstable.
  * Remove the "Team upload" for the last upload to experimental.

 -- Matthias Klose <email address hidden> Wed, 05 Dec 2018 09:06:06 +0100