JVM Crashing in Dockerized Alpine Environment about h3-java HOT 14 OPEN

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.

from h3-java.

Thanks for providing detailed steps for reproducing. I was able to reproduce the issue with the openjdk:8-alpine image.

After taking a look at the core dump, it looks like the issue is inside the function h3ToGeo. I noticed it calls a C core library function isfinite, and I was able to move the crash up in the call stack by adding a call to isfinite in jniapi.c. The issue is that the linux-x64 cross-compile build links to glibc, which is not available on Alpine Linux.

Since installing glibc on Alpine or statically linking with glibc are not recommended, it looks like the best approach here might be to change the linux-* cross-compile builds to statically link to musl.

from h3-java.

If this is the path we'll follow, I'd really enjoy opening a PR to change that during the weekend.
Are you aware of any dependency from glibc that is not available in musl?

from h3-java.

No, we shouldn't have any dependency on glibc itself. The core library has been tested with Alpine Linux and musl itself, and with MSVC.

cc @dfellis @isaachier @nrabinowitz in case there's something I'm not considering about statically linking to a different libc.

from h3-java.

@isaacbrodsky statically linking libc is generally a bad idea, and I think affects the licensing of the resulting binary (https://lwn.net/Articles/117972/), so H3 doesn't do that.

from h3-java.

@isaachier I believe the idea is to statically link musl, actualy. musl has a MIT license

from h3-java.

@dgmneto I think @isaacbrodsky helped me find the underlying problem. Here is a quote from the musl FAQ:

At present, some glibc-linked shared libraries can be loaded with musl, but all but the simplest glibc-linked applications will fail if musl is dropped-in in place of /lib/ld-linux.so.2.

https://www.musl-libc.org/faq.html

from h3-java.

I'll have to disagree with @dfellis on how uncommon Alpine is: in the docker world Alpine is usually used to reduce layer/image sizes. Even so, I get your point.
We are using H3 in a few Java applications rn, so I'll try to make a dockcross that uses musl-gcc and then I'll share here the results.

from h3-java.

@isaacbrodsky somewhat related question: Would it make sense to use -DCMAKE_BUILD_TYPE=RelWithDebInfo so the stacktraces aren't hex values?

from h3-java.

I don't want to get into a Linux distro flamewar (Linux is my daily driver, I've had enough of those over the years), I wanted to point out that we could easily tangle ourselves into a support nightmare when we look beyond the top 10 Linux distros (Alpine is currently 65th according to Distrowatch, and even in the world of Docker, Alpine has half the stars of Ubuntu).

from h3-java.

@dfellis I understand your position, but you'd be surprised about how many docker images use Alpine as a base. Stars aside, I wonder if there is a way to search for base image "spinoffs."

from h3-java.

See here for known issues with libraries on Alpine Linux: https://github.com/gliderlabs/docker-alpine/blob/master/docs/caveats.md.

from h3-java.

A good solution would be to package H3 itself as a package in Alpine, then H3-Java and other bindings can use the system provided core library.

edit: this would be limited by the need for JNI adapter functions.

The other option would be for Alpine users to build H3-Java on Alpine Linux and use the built artifact from there. That should be fully compatible with Alpine.

from h3-java.

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

from h3-java.