"insufficient memory" while running eclipse-temurin:17-jdk Docker image

7.2k views Asked by At

While running a ./mvnw clean package command inside Docker container running eclipse-temurin:17-jdk image, I got the following error (Maven doesn't even execute):

[0.002s][warning][os,thread] Failed to start thread "GC Thread#0" - pthread_create failed (EPERM) for attributes: stacksize: 1024k, guardsize: 4k, detached.
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Cannot create worker GC thread. Out of system resources.
# An error report file with more information is saved as:
# /home/myuser/hs_err_pid8.log

There were more information in hs_err_pid8.log file:

# There is insufficient memory for the Java Runtime Environment to continue.
# Cannot create worker GC thread. Out of system resources.
# Possible reasons:
#   The system is out of physical RAM or swap space
#   The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
#   JVM is running with Zero Based Compressed Oops mode in which the Java heap is
#     placed in the first 32GB address space. The Java Heap base address is the
#     maximum limit for the native heap growth. Please use -XX:HeapBaseMinAddress
#     to set the Java Heap base and to place the Java Heap above 32GB virtual address.
# This output file may be truncated or incomplete.
#
#  Out of Memory Error (workerManager.hpp:87), pid=8, tid=8
#
# JRE version:  (17.0.5+8) (build )
# Java VM: OpenJDK 64-Bit Server VM (17.0.5+8, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)

How can I fix this?

1

There are 1 answers

1
Anthony O. On

Adding --security-opt seccomp=unconfined argument to the docker run command fixed my issue.

Thanks to this SO answer that pointed out seccomp Docker security profile & official documentation.