OM Open Make Meister java.lang.OutOfMemoryError: Cannot create GC thread. Out of system resources Error

book

Article ID: 131248

calendar_today

Updated On:

Products

CA Harvest Software Change Manager - OpenMake Meister

Issue/Introduction

Running /app/openmake/client/bin/runant.pl -buildfile build_ProviderAddressMaintenanceWorkflow_wsclient_javac.xml 

# A fatal error has been detected by the Java Runtime Environment: 

# java.lang.OutOfMemoryError: Cannot create GC thread. Out of system resources. 

# Internal Error (gcTaskThread.cpp:38), pid=15390, tid=1446357872 
# Error: Cannot create GC thread. Out of system resources. 

# JRE version: 6.0_22-b04 
# Java VM: Java HotSpot(TM) Server VM (17.1-b03 mixed mode linux-x86 ) 
# An error report file with more information is saved as: 
# /app/build/builds/Unit/LEDSIntegrationClients_1/2019-04-22_16_06_54/hs_err_pid15390.log 

# If you would like to submit a bug report, please visit: 
# http://java.sun.com/webapps/bugreport/crash.jsp 


java.lang.OutOfMemoryError: Cannot create GC thread. Out of system resources build_ProviderAddressMaintenanceWorkflow_wsclient_javac.xml 

# A fatal error has been detected by the Java Runtime Environment: 

# java.lang.OutOfMemoryError: Cannot create GC thread. Out of system resources. 

# Internal Error (gcTaskThread.cpp:38), pid=15390, tid=1446357872 
# Error: Cannot create GC thread. Out of system resources. 

# JRE version: 6.0_22-b04 
# Java VM: Java HotSpot(TM) Server VM (17.1-b03 mixed mode linux-x86 ) 
# An error report file with more information is saved as: 
# /app/build/builds/Unit/LEDSIntegrationClients_1/2019-04-22_16_06_54/hs_err_pid15390.log 

# If you would like to submit a bug report, please visit: 
# http://java.sun.com/webapps/bugreport/crash.jsp 


Script took: 1 wallclock secs ( 0.03 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.04 CPU) 

Cause

ulimit settings are not properly configured.

Other Possible reason:
# The system is out of physical RAM or swap space 
 

Environment

Release:
Component: CCCHV

Resolution

Reverting our ulimit values from unlimited back to a capped number fix the problem.


Other Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)