SEGFAULT with native images fully static performing DNS lookup #571
Assignees
Labels
Comments
|
@pmlopes please provide me a minimal sample along with build and run instructions so that I can investigate further. Thanks! |
|
Here a reproducer: dns-issue.zip I've reduced the code to: import java.net.InetAddress;
class Main {
public static void main(String[] args) throws Exception {
InetAddress.getByName("www.google.com");
}
}And to be sure that it's not an issue of building on my machine I've included a # GraalVM docker image used for AoT compilation
FROM panga/graalvm-ce:latest AS build-aot
# Add maven wrapper
ADD mvnw app/
ADD mvnw.cmd app/
ADD .mvn app/.mvn/
RUN cd /app && \
./mvnw -version
# Add pom and download dependencies
ADD pom.xml app/
RUN cd /app && \
./mvnw dependency:copy-dependencies
# Add sources
ADD src app/src/
# Set working dir
WORKDIR /app
# Build (java side)
RUN ./mvnw package
# Build image
RUN native-image \
--no-server \
--static \
-Djava.net.preferIPv4Stack=true \
-H:+ReportUnsupportedElementsAtRuntime \
-jar "target/dns.jar"
# Create new image from scratch
FROM alpine
# Copy generated native executable from build-aot
COPY --from=build-aot /app/dns /dns
# Set the entrypoint
ENTRYPOINT [ "/dns" ]And the execution ends with the same result as seen on the initial report. |
|
thanks! i will have a look. |
|
The problem is that dns lookup on modern systems always requires dynamically linked libc. Despite having a static binary it will do the following: |
|
If I add all the shared objects the Then in the Dockerfile I add |
|
The above being said there is one possible route you could take if you insist on having a fully static binary even for such usecases. See https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F So you can either build yourself a system (a docker image) that has c-library built with |
|
@olpaw thanks. The goal here was to make the smallest image, like one would with |
|
Ran into this issue as well. Here is the terrible workaround: |
|
We have a better solution for this now. Build a static image with muslc. @gradinac knows all about it. |
thiagokokada
added a commit
to thiagokokada/babashka
that referenced
this issue
May 9, 2021
This is the recommended way to build static binaries with GraalVM by the documentation and multiple issues on GitHub. See: - https://www.graalvm.org/reference-manual/native-image/StaticImages/ - oracle/graal#571 (comment) The reason that building a statically binary with glibc is complicated is explained in the glib documentation: https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F To build a static binary with Dockerfile, use: ``` $ docker build -t babashka . \ --build-arg BABASHKA_STATIC=true \ --build-arg BABASHKA_USE_MUSL=true \ --build-arg BABASHKA_XMX="-J-Xmx16g" ```
thiagokokada
added a commit
to thiagokokada/babashka
that referenced
this issue
May 9, 2021
Based on babashka/pod-babashka-aws#37. This is the recommended way to build static binaries with GraalVM by the documentation and multiple issues on GitHub. See: - https://www.graalvm.org/reference-manual/native-image/StaticImages/ - oracle/graal#571 (comment) The reason that building a statically binary with glibc is complicated is explained in the glib documentation: https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F
thiagokokada
added a commit
to thiagokokada/babashka
that referenced
this issue
May 9, 2021
Based on babashka/pod-babashka-aws#37. This is the recommended way to build static binaries with GraalVM by the documentation and multiple issues on GitHub. See: - https://www.graalvm.org/reference-manual/native-image/StaticImages/ - oracle/graal#571 (comment) The reason that building a statically binary with glibc is complicated is explained in the glib documentation: https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F
borkdude
pushed a commit
to babashka/babashka
that referenced
this issue
May 9, 2021
* Build BABASHKA_STATIC with musl C library Based on babashka/pod-babashka-aws#37. This is the recommended way to build static binaries with GraalVM by the documentation and multiple issues on GitHub. See: - https://www.graalvm.org/reference-manual/native-image/StaticImages/ - oracle/graal#571 (comment) The reason that building a statically binary with glibc is complicated is explained in the glib documentation: https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F * Bring back zlib1g-dev Seems it is necessary for the non-static build.
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I was trying to build a image that already works when using shared objects with the extra flag:
--static.The application crashes as soon as a DNS resolution is requested:
The text was updated successfully, but these errors were encountered: