Regression: SIGSEGV running Java

[pgnd]

I've Raspbian9 installed in a CHROOT on x86_64.

In the chroot,

 dpkg -l | grep jdk
  ii openjdk-8-jdk-headless:armhf 8u151-b12-1~deb9u1 armhf OpenJDK Development Kit (JDK) (headless)
  ii openjdk-8-jre-headless:armhf 8u151-b12-1~deb9u1 armhf OpenJDK Java runtime, using Hotspot JIT (headless)

Building Kodi18, at a swig/groovy code generator step, java build SIGSEGVs:

 cd /usr/local/src/kodi/build/build/build/swig && /usr/bin/java -cp /usr/local/src/kodi/tools/codegenerator/groovy/groovy-all-2.4.4.jar:/usr/local/src/kodi/tools/codegenerator/groovy/commons-lang-2.6.jar:/usr/local/src/kodi/tools/codegenerator:/usr/local/src/kodi/xbmc/interfaces/swig/../python groovy.ui.GroovyMain /usr/local/src/kodi/tools/codegenerator/Generator.groovy AddonModuleXbmcwsgi.i.xml /usr/local/src/kodi/xbmc/interfaces/swig/../python/PythonSwig.cpp.template AddonModuleXbmcwsgi.i.cpp

  #
  # A fatal error has been detected by the Java Runtime Environment:
  #
  # SIGSEGV (0xb) at pc=0xf506b558, pid=63424, tid=0xf4980470
  #
  # JRE version: OpenJDK Runtime Environment (8.0_151-b12) (build 1.8.0_151-8u151-b12-1~deb9u1-b12)
  # Java VM: OpenJDK Client VM (25.151-b12 mixed mode linux-aarch32 )
  # Problematic frame:
  # V [libjvm.so+0x4e4558]
  #
  # Core dump written. Default location: /usr/local/src/kodi/build/build/build/swig/core or core.63424
  #
  # An error report file with more information is saved as:
  # /usr/local/src/kodi/build/build/build/swig/hs_err_pid63424.log
  Compiled method (c1) 1446 35 java.io.DataInputStream::readFully (63 bytes)
   total in heap [0xf2742a48,0xf2742f20] = 1240
   relocation [0xf2742b14,0xf2742b68] = 84
   main code [0xf2742b80,0xf2742d40] = 448
   stub code [0xf2742d40,0xf2742db8] = 120
   metadata [0xf2742db8,0xf2742dd0] = 24
   scopes data [0xf2742dd0,0xf2742e7c] = 172
   scopes pcs [0xf2742e7c,0xf2742f1c] = 160
   dependencies [0xf2742f1c,0xf2742f20] = 4
  Compiled method (c1) 1447 35 java.io.DataInputStream::readFully (63 bytes)
   total in heap [0xf2742a48,0xf2742f20] = 1240
   relocation [0xf2742b14,0xf2742b68] = 84
   main code [0xf2742b80,0xf2742d40] = 448
   stub code [0xf2742d40,0xf2742db8] = 120
   metadata [0xf2742db8,0xf2742dd0] = 24
   scopes data [0xf2742dd0,0xf2742e7c] = 172
   scopes pcs [0xf2742e7c,0xf2742f1c] = 160
   dependencies [0xf2742f1c,0xf2742f20] = 4
  Compiled method (c1) 1448 35 java.io.DataInputStream::readFully (63 bytes)
   total in heap [0xf2742a48,0xf2742f20] = 1240
   relocation [0xf2742b14,0xf2742b68] = 84
   main code [0xf2742b80,0xf2742d40] = 448
   stub code [0xf2742d40,0xf2742db8] = 120
   metadata [0xf2742db8,0xf2742dd0] = 24
   scopes data [0xf2742dd0,0xf2742e7c] = 172
   scopes pcs [0xf2742e7c,0xf2742f1c] = 160
   dependencies [0xf2742f1c,0xf2742f20] = 4
  Compiled method (c1) 1448 35 java.io.DataInputStream::readFully (63 bytes)
   total in heap [0xf2742a48,0xf2742f20] = 1240
   relocation [0xf2742b14,0xf2742b68] = 84
   main code [0xf2742b80,0xf2742d40] = 448
   stub code [0xf2742d40,0xf2742db8] = 120
   metadata [0xf2742db8,0xf2742dd0] = 24
   scopes data [0xf2742dd0,0xf2742e7c] = 172
   scopes pcs [0xf2742e7c,0xf2742f1c] = 160
   dependencies [0xf2742f1c,0xf2742f20] = 4
  #
  # If you would like to submit a bug report, please visit:
  # http://bugreport.java.com/bugreport/crash.jsp
  #
  Aborted (core dumped)

Several references report similar in qemu env. Per,

 Regression: SIGSEGV running Java
  https://bugs.launchpad.net/qemu/+bug/1659901

  "Additional investigation reveals the problem has something to do with the Azul ARM32 JIT. If I run Java with -Xint to force interpreter-only mode, this problem doesn't occur."

turning ON interpreter-only mode,

 cd /usr/local/src/kodi/build/build/build/swig && /usr/bin/java -Xint -cp /usr/local/src/kodi/tools/codegenerator/groovy/groovy-all-2.4.4.jar:/usr/local/src/kodi/tools/codegenerator/groovy/commons-lang-2.6.jar:/usr/local/src/kodi/tools/codegenerator:/usr/local/src/kodi/xbmc/interfaces/swig/../python groovy.ui.GroovyMain /usr/local/src/kodi/tools/codegenerator/Generator.groovy AddonModuleXbmcwsgi.i.xml /usr/local/src/kodi/xbmc/interfaces/swig/../python/PythonSwig.cpp.template AddonModuleXbmcwsgi.i.cpp

the build completes without error.

[pgnd (pgnd)]

for ref,

diff of compiled vs interpreted output, 'java -XshowSettings -version' vs 'java -Xint -XshowSettings -version' :

  https://www.diffchecker.com/X1dsWWYI

[peter green (plugwash)]

Does this happen on actual arm hardware? If not then i'm inclined to say it is a bug in whatever emulator you are using and not a bug in raspbian per-se.

[pgnd (pgnd)]

> Does this happen on actual arm hardware? If not then i'm inclined to say it is a bug in whatever emulator you are using and not a bug in raspbian per-se.

Nope, it does not. On 'real HW', an RPi2, it's OK.

Several comments at the referenced bug(s) suggest it's an issue only in QEMU chroot ... but, with newer/current pkg'd jdk.

Supposedly -- untested here, yet, until I can find where to grab it -- older jdk has no such issues.

As Raspbian "in a chroot" is a pretty common/useful chroot env, this certainly "affects" it. In the "it takes two to tango" sense ...

Although it's most likely not Raspbian's "fault", but rather of the JDK &/or qemu, what version of jdk Raspbian pkgs _is_ under control here.

[peter green (plugwash)]

There are a couple of issues here.

Firstly as I understand it the Debian Java folks have decided (rightly or wrongly) that separating out the security updates from the other updates in a Java release series is impractical. The result is that Debian (and hence raspbian) stable end up getting java updates that include a mixture of security and other updates.

Secondly qemu (especially user mode qemu) is far from a perfect emulator.

I understand qemu chroots are useful and regressions are annoying but any improvements to support for qemu users must not come at the expense of the actual intended users of the port.

[pgnd (pgnd)]

Didn't know about the lack-of-separation point. Sounds like it'd be pushing rocks uphill to try to get that to change.

As for "but any improvements to support for qemu users must not come at the expense of the actual intended users of the port.", I hear ya & certainly agree with the principle.

That said, there's perspective here ...

Raspbian 'on' RPi being the 'actual intended' use, *building* on the HW is (arguably) less than optimal. The option to build 'hefty' packages (e.g. Kodi) either via cross-compile (currently 'challenged' as well) or chroot'd Raspbian, on more performant/resilient HW is, for some usage, not really an option. No Raspbian chroot build, no Raspbian use on Rpi2.

I.e., the LACK of support for qemu users DOES come at the expense of the actual intended users of the port.

Again, simply a matter of use-case perspective.

Couple of interim workrounds include:

(1) IS there a Raspbian UNstable repo, specifically with a newer JDK? either jdk8-nightly, or jdk9? Those _might_ have intentional, or inadvertent, fixes.

(2) IS there an older Raspbian repo that holds an earlier jdk8? IIRC, Wheezy has only jdk7?

(3) Arch-for-ARM may be a more flexible option; need to poke around in their JAVA build env to see what's what.

[peter green (plugwash)]

> (1) IS there a Raspbian UNstable repo, specifically with a newer JDK? either jdk8-nightly, or jdk9? Those _might_ have intentional, or inadvertent, fixes.

No unstable but there is a testing repo and it does have openjdk-9 packages.

> (2) IS there an older Raspbian repo that holds an earlier jdk8? IIRC, Wheezy has only jdk7?

Looks like raspbian jessie has 8u40 (though it probablly shouldn't have....). You can also find older snapshots of the raspbian repo on snapshot.raspbian.org .

[pgnd (pgnd)]

Thx, I'll poke at those.

fyi, noting

 "Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation"
  http://lists.nongnu.org/archive/html/qemu-devel/2014-03/msg01850.html
    Mon, 10 Mar 2014 14:56:40 +0100 (CET)
  "Generally speaking, yes. I've never seen problems with openjdk (with the suse tree), so the segfault above might be also be related to the segfault handling for read-only data segments containing code (the signal trampoline on stack), for which the patches were recently proposed upstream."

& switching to OpenSUSE Leap 42.3 chroot,

 lsb_release -rd
  Description: openSUSE Leap 42.3
  Release: 42.3
 uname -rm
  4.14.0-2.gab9e909-default armv7l

with

 rpm -qa | grep -i openjdk
  java-1_8_0-openjdk-headless-1.8.0.151-18.1.armv7hl

and same host OS / qemu static bins,

whereas Raspbian's JDK,

 openjdk version "1.8.0_151"
 OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-1~deb9u1-b12)
 OpenJDK Client VM (build 25.151-b12, interpreted mode)

in the OpenSUSE chroot, there's no such SIGSEGV problem; all's OK

 java -XshowSettings -version
  VM settings:
      Max. Heap Size (Estimated): 989.88M
      Ergonomics Machine Class: server
      Using VM: OpenJDK Client VM

  Property settings:
      awt.toolkit = sun.awt.X11.XToolkit
      awt.useSystemAAFontSettings = on
      file.encoding = UTF-8
      file.encoding.pkg = sun.io
      file.separator = /
      java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
      java.awt.headless = true
      java.awt.printerjob = sun.print.PSPrinterJob
      java.class.path = .
      java.class.version = 52.0
      java.endorsed.dirs = /usr/lib/jvm/java-1.8.0-openjdk-1.8.0/jre/lib/endorsed
      java.ext.dirs = /usr/lib/jvm/java-1.8.0-openjdk-1.8.0/jre/lib/ext
          /usr/java/packages/lib/ext
      java.home = /usr/lib/jvm/java-1.8.0-openjdk-1.8.0/jre
      java.io.tmpdir = /tmp
      java.library.path = /usr/java/packages/lib/aarch32
          /lib
          /usr/lib
      java.runtime.name = OpenJDK Runtime Environment
      java.runtime.version = 1.8.0_151-b12
      java.specification.name = Java Platform API Specification
      java.specification.vendor = Oracle Corporation
      java.specification.version = 1.8
      java.vendor = Oracle Corporation
      java.vendor.url = http://java.oracle.com/
      java.vendor.url.bug = http://bugreport.sun.com/bugreport/
      java.version = 1.8.0_151
      java.vm.info = mixed mode
      java.vm.name = OpenJDK Client VM
      java.vm.specification.name = Java Virtual Machine Specification
      java.vm.specification.vendor = Oracle Corporation
      java.vm.specification.version = 1.8
      java.vm.vendor = Oracle Corporation
      java.vm.version = 25.151-b12
      line.separator = \n
      os.arch = arm
      os.name = Linux
      os.version = 4.14.0-2.gab9e909-default
      path.separator = :
      sun.arch.data.model = 32
      sun.boot.class.path = /usr/lib/jvm/java-1.8.0-openjdk-1.8.0/jre/lib/resources.jar
          /usr/lib/jvm/java-1.8.0-openjdk-1.8.0/jre/lib/rt.jar
          /usr/lib/jvm/java-1.8.0-openjdk-1.8.0/jre/lib/sunrsasign.jar
          /usr/lib/jvm/java-1.8.0-openjdk-1.8.0/jre/lib/jsse.jar
          /usr...