A fatal error running java-client SDK 3.2.1 running on alpine 3.14

Hi, I’m currently upgrading java SDK from 2.7 to 3.2.1 and running on alpine container errors with fatal exception.

# A fatal error has been detected by the Java Runtime Environment:
# SIGSEGV (0xb) at pc=0x000000000000401e, pid=1357, tid=1388
# JRE version: OpenJDK Runtime Environment (11.0.11+9) (build 11.0.11+9-alpine-r0)
# Java VM: OpenJDK 64-Bit Server VM (11.0.11+9-alpine-r0, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C 0x000000000000401e
# No core dump will be written. 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:
# /usr/src/app/hs_err_pid1357.log
# If you would like to submit a bug report, please visit:
# https://gitlab.alpinelinux.org/alpine/aports/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.

Am I missing any required dependencies in the container?

Hi @haroon.sheikh
These kinds of crashes with JRE on Alpine are common due to the musl libc, so currently I’d recommend using one of the openjdk images instead. There’s some good background reading on Stackoverflow here: Why new Java 8 images published by OpenJDK are no longer Alpine based but Debian 10(Buster) based? - Stack Overflow and java - Docker images - types. Slim vs slim-stretch vs stretch vs alpine - Stack Overflow.

We do have long-term plans to support Alpine with the SDKs - please see Log in - Couchbase database for tracking.

1 Like

Thanks for getting back @graham.pople.

Unfortunately, all of our build containers are alpine based and it wont be an easy job to migrate them all.

I don’t seem to have access to the Jira board you shared?

Ah, that type of issue is apparently not generally visible. Currently it essentially says that we have plans to support Alpine on the SDKs, but there is not a timeline at this moment. I will update here once things change.

we are facing the same , so can u please put some priority on it , and which OpenJdk 11 slim it works with pls ?


Netty does not support the native transport (epoll) when running under musl since it’s compiled against glibc. And it not nicely bails out but segfaults … until they fix it (there is no date yet) there is no other way around it at the moment to handle it automatically by the SDK.

That said, there are two ways to solve this:

  • Don’t use alpine in the first place - use a OpenJDK image which uses glibc (pretty much any that is not using alpine)
  • Disable the native IO ClusterEnvironment env = ClusterEnvironment.builder().ioEnvironment(IoEnvironment.enableNativeIo(false)).build();

If you disable the native IO in your code it won’t try to load the native code and then it should also work under alpine.

@daschl many thanks man for the detailed response which what I was looking for to understand what options we have .

1 Like

We’ve faced the same issue during migration to jdk-17:

openjdk version "17-ea" 2021-09-14
OpenJDK 64-Bit Server VM (build 17-ea+14, mixed mode, sharing)

Alpine Linux v3.14

Couchbase client version: 3.2.6

Please advise whether there is a client version with the fix of the issue ?

Hi @dmly, welcome to the Couchbase Forum!

I’d recommend upgrading to Couchbase Java SDK 3.4.2 or later to pick up the fix for JVMCBC-1176. Then disable native IO and native TLS as described in the SDK’s Alpine Linux compatibility documentation.


Hi @david.nault

Thanks for your response!