My coworkers and I have flagged a new behavior with the latest versions of Knime. If you leave it idle for a while and do other things or leave your computer, Knime will shutdown and lose all of your unsaved work/executed nodes. Not all the time, but it’s happened several on occasions since I upgraded to 5.5.1. I also just had Knime crash and shutdown out of nowhere while running a workflow, not idle. This all seems new to the latest updates. Is this happening to others? It’s very inconvenient behavior for complex workflows that need a lot of time and storage to run.
Hi @cbirch , the only time I’vew seen this kind of crash has been to do with memory allocation. How much memory does you system have, and how much is allocated to KNIME in the knime.ini file?
e.g. in my knime.ini file (located in the same folder as knime.exe, it is set to a maximum of 10G
-Xmx10g
If the crash is caused by memory allocation, then you would probably also find some log files created
by the java vm in the same folder. They will have names like this:
hs_err_pid12345.log
e.g.
The above are error logs for my KNIME 5.4.4 installation. I have recently had “sudden death” KNIME crashes caused by memory non-availability. Basically I had previously had KNIME configured for 12G max memory but I have other apps running on my laptop which meant that when KNIME attempted to grab all 12G, it wasn’t available and it crashed the java virtual machine.
This is what the resultant log looked like:
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 989855744 bytes for G1 virtual space
# 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 (os_windows.cpp:3548), pid=33116, tid=20408
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.5+8 (17.0.5+8) (build 17.0.5+8)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.5+8 (17.0.5+8, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
If it is this problem, you actually need to reduce the amount of memory specified in the KNIME.INI which sounds counter-intuitive. The issue occurs when KNIME (or more correctly, java) is told that it has more memory available than is actually obtainable on the system (when all other processes are taken into account).
I give a slightly more detailed explanation and example in this post:
Of course if those log files don’t exist in your system, then this could be something else, or possibly there is something about the amount of memory that the later versions of KNIME are using, but max memory allocation configuration (-xmx) is the first place I would look.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.