search

sgerrand / alpine-pkg-glibc

A glibc compatibility layer package for Alpine Linux
2.05k stars 280 forks source link

Segmentation fault in libc.so.6 when running Oracle JDK 10 #75

Closed aaronjwhiteside closed 2 months ago

aaronjwhiteside commented 6 years ago

Using the latest 2.27

Stack: [0x00007f1a40bdd000,0x00007f1a40cde000],  sp=0x00007f1a40cda1f0,  free space=1012k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x5ad48]  _IO_vfscanf+0xc8
C  [libc.so.6+0x6ec67]  vsscanf+0x67
PAX523 commented 6 years ago

JRE 9 dies as well:

Stack: [0x00007fc105540000,0x00007fc10563f000],  sp=0x00007fc10563cb20,  free space=1010k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x4f3ef]
C  [libc.so.6+0x4ca79]  _IO_vfprintf+0xe09
C  [libc.so.6+0x75259]  vsnprintf+0x79
V  [libjvm.so+0x5d4e33]  CodeBuffer::relocate_code_to(CodeBuffer*) const+0x263
sgerrand commented 6 years ago

This is most certainly an issue with both Java 9 and 10. I haven't been able to get either of them to run using this package since Java 9 was released in 2017.

Unfortunately I haven't been able to find time as yet to investigate the cause of these segfaults further.

sgerrand commented 6 years ago

@aaronjwhiteside, @PAX523: Thank you for reporting this issue. Would you please let me know what version of Alpine was affected, how you are running it (e.g. in Docker or otherwise) and the major and minor version of the (Oracle, I assume) JDK you ran. Thanks in advance!

aaronjwhiteside commented 6 years ago

Alpine 3.7 and tested with Oracle JDK 9.0.4 and 10 (latest stable release), this was in docker.

I ended up getting it working by copying adopt openjdk's approach, https://github.com/AdoptOpenJDK/openjdk-docker/blob/master/9/jdk/alpine/Dockerfile.openj9#L32

Where they use the official libgcc and libstdc++ .so's from arch linux, I had to add in arch linux's libz as well but otherwise it works perfectly now both for JDK 9 and 10.

I hope this helps others..

PAX523 commented 6 years ago

I was running:

xfournet commented 6 years ago

Following the advice from @aaronjwhiteside I was able to workaround the problem by just adding the libz from arch linux.

FROM frolvlad/alpine-glibc:alpine-3.8

RUN wget "https://www.archlinux.org/packages/core/x86_64/zlib/download" -O /tmp/libz.tar.xz \
    && mkdir -p /tmp/libz \
    && tar -xf /tmp/libz.tar.xz -C /tmp/libz \
    && cp /tmp/libz/usr/lib/libz.so.1.2.11 /usr/glibc-compat/lib \
    && /usr/glibc-compat/sbin/ldconfig \
    && rm -rf /tmp/libz /tmp/libz.tar.xz
xfournet commented 6 years ago

Since the librairies in /lib are not compatible with glibc program, shouldn't the glibc package also includes theses libraries (zlib and libressl) to avoid crash when an glibc program depends on some of them ?

sgerrand commented 6 years ago

Since the librairies in /lib are not compatible with glibc program, shouldn't the glibc package also includes theses libraries (zlib and libressl) to avoid crash when an glibc program depends on some of them ?

The short answer is no. If you're running a program which relies on glibc inside a musl-libc based operating system like Alpine Linux, then you need to include whatever dependencies your program may require. Just because a program has been compiled against glibc does not mean that it requires another library like zlib.

henrik242 commented 5 years ago

@xfournet Is this still the preferred workaround?

xfournet commented 5 years ago

@henrik242 the workaround should still work. However for my use case, i created two new Docker image (https://hub.docker.com/r/xfournet/jready/) targeting the execution of a JRE. One is based on alpine docker image and this alpine-pkg-glibc with some changes to prevent glibc lib's and musl lib's to be mixed, so it should prevent such crash. Theses changes could be ported back to alpine-pkg-glibc, @sgerrand let me know if you want that i create a pull request for that (see https://github.com/xfournet/jready/blob/master/alpine/Dockerfile#L71 ) ? If you don't need apk tool you can use the other one that is based on busybox-glibc.

plo- commented 5 years ago

Thanks @xfournet for your workaround, you saved my day!

henrik242 commented 5 years ago

By the way, I switched to the AdoptOpenJDK 10 (and 11) alpine images (e.g. adoptopenjdk/openjdk11:alpine-slim), now I don't have to bother with any glibc hacks.

See also

sgerrand commented 5 years ago

Glad to hear that you got so much benefit from this package in the interim.

On Tue, 16 Oct 2018, 16:50 henrik242 notifications@github.com wrote:

By the way, I switched to the alpine OpenJDK 10 (and 11) images by Adopt (e.g. adoptopenjdk/openjdk11:alpine-slim), now I don't have to bother with any glibc hacks.

See also

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sgerrand/alpine-pkg-glibc/issues/75#issuecomment-430291157, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMaZjxGpmf2HS48yDXEYVnVJnr-0rWxks5ulgAxgaJpZM4S6AnY .

henrik242 commented 5 years ago

AdoptOpenJDK also use this package, so it's all good :)

LinjingBi commented 4 years ago

Thanks for the fix. I think it would be better to use mv to move the libz.so to /usr/glibc-compat/lib, since there are some symlinks under that dir. And it still works in glibc-2.31-r0
wget "https://www.archlinux.org/packages/core/x86_64/zlib/download" -O /tmp/libz.tar.xz \
&& mkdir -p /tmp/libz \ && tar -xf /tmp/libz.tar.xz -C /tmp/libz \ && mv /tmp/libz/usr/lib/libz.so /usr/glibc-compat/lib \ && rm -rf /tmp/libz /tmp/libz.tar.xz

sgerrand commented 2 months ago

I'm so sorry for not responding to this bug report sooner. Without an example Dockerfile it's hard to know what's causing these segmentation faults. If you're still experiencing this problem then would you please reply with an example Dockerfile which reproduces the error.

I suggest that you and any other future readers in a situation like this consider running containers based on Docker images that are based on a GNU C library, rather than trying to run binaries which weren't compiled for musl inside Alpine Linux. As an example, Debian currently provide "slim" Docker images for each of their releases which are ~ 30 MB compressed.