# A fatal error has been detected by the Java Runtime Environment:
# java.lang.OutOfMemoryError: requested 174248 bytes for Chunk::new. Out of swap space?
# Internal Error (allocation.cpp:215), pid=3240, tid=5124
# Error: Chunk::new
# JRE version: 6.0_14-b08
# Java VM: Java HotSpot(TM) Server VM (14.0-b16 mixed mode windows-x86 )
# An error report file with more information is saved as:
# S:SelfmadeIntelliJ ProjectsHHexen XXXtrunkhs_err_pid3240.log
# If you would like to submit a bug report, please visit:
but which memory is it? my vm has -Xmx700m - if that is not enough, a "normal OOME" should be thrown.
my machine has 8 gig, 4 of them free, so "out of swap space" can't be the reason either.
If it's of any help I've experienced this exact problem, although it was a while ago …for me the cause was down to declaring a -Xmx argument, then exceeding / using more memory then I requested.
The short term solution was to increase the -Xmx value, then to profile and improve my memory usage, turns out I was loading far too many models :-o
As I recall there is also a limit on the maximum value you can set for the -Xmx (based on the Java VM) irrespective of memory available to your OS, think for my PC it's was 1.5 gig despite having 3.2 gig plug in.
i guess that's it. the error occurs when adding a bunch of enemies to a running game (meaning: loading md2 & ms3d-models). what's the default value for the max size? never heard of that option before.
i already fixed the problem by detaching the nodes containing all the animated meshes when an object is not rendered for some time and recreate and attach them when the player looks at them again. it's a pretty good solution as it now is possible to leave only the logical data in memory (a few kb per object i guess) if the player decides to run away from an army and dynamically load the models again when the player returns.
it's also pretty funny to know that as soon as you turn away from the enemy, he transforms into a simple box and throws little boxes at other boxes which in turn die and bleed. but as soon as you look there - all is fine :D
Hm apperently it's based on -Xmx on modern VMs, so maybe you were just hitting that 700m limit. If you run into it again, enable dumping of a stacktrace (if it's not already in that hs_err_pid3240.log file), you can see which method caused it.