[gentoo) insufficient memory for the JRE to continue.

111 views
Skip to first unread message

Dima Pasechnik

unread,
May 14, 2019, 5:12:12 AM5/14/19
to sage-devel
Lately I get this error a lot on a gentoo machine, in form of files
named like hs_err_pid<...>.log in SAGE_ROOT.

After a run of make ptest, there are about a hundred of these appearing.
Any idea how this can be fixed?
The machine in question has 8 GB of RAM...

These files start like this:

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 312 bytes for
AllocateHeap
# Possible reasons:
# The system is out of physical RAM or swap space
# In 32 bit mode, the process size limit was hit
# 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)
# Decrease number of Java threads
# Decrease Java thread stack sizes (-Xss)
# Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
# Out of Memory Error (allocation.inline.hpp:61), pid=5255,
tid=0x00007fa918622700
#
# JRE version: (8.0_191-b12) (build )
# Java VM: OpenJDK 64-Bit Server VM (25.191-b12 mixed mode linux-amd64
compressed oops)
# Derivative: IcedTea 3.10.0
# Distribution: Gentoo Base System release 2.6, package Gentoo icedtea-3.10.0
# Failed to write core dump. Core dumps have been disabled. To enable
core dumping, try "ulimit -c unlimited" before starting Java again
#

--------------- T H R E A D ---------------

Current thread (0x00007fa914094800): JavaThread "Finalizer" daemon
[_thread_in_vm, id=5265, stack(0x00007fa918522000,0x00007fa918623000)]

Stack: [0x00007fa918522000,0x00007fa918623000],
sp=0x00007fa9186218a0, free space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x965909]

Timo Kaufmann

unread,
Aug 3, 2019, 4:45:43 PM8/3/19
to sage-devel
It's been a while, but now we are seeing a similar issue here[1]. In our case it fails the doctests, seems to be jmol running out of memory.

Eric Gourgoulhon

unread,
Aug 5, 2019, 11:30:19 AM8/5/19
to sage-devel
Le samedi 3 août 2019 22:45:43 UTC+2, Timo Kaufmann a écrit :
It's been a while, but now we are seeing a similar issue here[1]. In our case it fails the doctests, seems to be jmol running out of memory.


Eric.

E. Madison Bray

unread,
Aug 5, 2019, 1:51:06 PM8/5/19
to sage-devel
If I recall correctly, I noticed that in Debian's package for Sage
8.6, they already patched it to make threejs the default.

Whatever minor bugs remain with threejs maybe we should go ahead and
just switch the default, and for the few issues where threejs isn't
the best viewer it's still possible to switch to another, including
jmol, where available...
Reply all
Reply to author
Forward
0 new messages