JVM Crashing in Dockerized Alpine Environment

This is the code I’m using to reproduce the problem:

import com.uber.h3core.H3Core;

import java.io.IOException;

public class Main {
    private static final double[][] coordinates = new double[][] {
            {0.0    , 90.0    },
            {13.5467, -19.2347},
            {13.5467, -30.2347},
            {17.5467, -30.2347}
    };

    public static void main(String[] args) throws IOException {
        H3Core h3Core = H3Core.newInstance();
        for (double[] coordinate: coordinates) {
            long h3Id = h3Core.geoToH3(coordinate[0], coordinate[1], 12);
            System.out.printf("Lat: %s Lng: %s H3: %d%n", coordinate[0], coordinate[1], h3Id);
        }
    }
}

I’m using the gradle docker plugin to build the docker images. The project with the crashing scenario and setup is available here. To build the image, run ./gradlew dockerBuildImage. Then run docker run -it divinomenezes/h3-issue-test:latest to run the code. You should be able to run normally. If you change the build.gradle:27 as described in the comment and rerun the steps above, you should see the following error:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000003b36, pid=1, tid=0x00007fbaf7e76ae8
#
# JRE version: OpenJDK Runtime Environment (8.0_171-b11) (build 1.8.0_171-b11)
# Java VM: OpenJDK 64-Bit Server VM (25.171-b11 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea 3.8.0
# Distribution: Custom build (Wed Jun 13 18:28:11 UTC 2018)
# Problematic frame:
# C  0x0000000000003b36
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# //hs_err_pid1.log
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
#

The hs_err_pid1.log is also available here.

[dfellis]

I don’t really like the idea of statically linking Musl to support one uncommon Linux variant. If we’re going to support this, I’d rather we do some autoconf-like detection of which library, glibc or musl, to link to, and to use the OS-provided one. Otherwise we’re opening ourselves to an upgrade treadmill for all security updates to musl.

[isaachier]

Yes that would work but you will have a lot of package systems to work with (debian, rpm, etc.).