After the deadline, we should make an example that reproduces the SIGSEGV problem. Unfortunately, it is not very easy to reproduce but the interesting thing is, that Maple always runs into SIGSEGV in the exact same location:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f2130ed2f5e, pid=348362, tid=348596
#
# JRE version: OpenJDK Runtime Environment (11.0.9.1+1) (build 11.0.9.1+1-Ubuntu-0ubuntu1.20.10)
# Java VM: OpenJDK 64-Bit Server VM (11.0.9.1+1-Ubuntu-0ubuntu1.20.10, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C [libmaple.so+0x121f5e]
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /mnt/share/Projects/vmext-demo/core.348362)
#
# If you would like to submit a bug report, please visit:
# https://bugs.launchpad.net/ubuntu/+source/openjdk-lts
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
After the deadline, we should make an example that reproduces the SIGSEGV problem. Unfortunately, it is not very easy to reproduce but the interesting thing is, that Maple always runs into SIGSEGV in the exact same location:
So it is always:
That might help already to find the memory leak.
(Referenced to #205)