This is a follow-up message regarding my earlier topic: TVersionCheck crashing MATLAB
As mentioned in the earlier topic, using ROOT in MATLAB currently causes MATLAB to eventually crash. This is caused by incompatibility between ROOT (more specifically the TVersionCheck) and the Java virtual machine used in MATLAB (more on this below). The easiest way to circumvent this (and to prevent the crash) is to run MATLAB with -nojvm. However, you will have zero GUI/graphics capabilities then.
Starting from R2019a, there is another way to prevent the crash and that is by using mexhost and the C++ mex interface. For some examples on how to use these with ROOT you can see the code I’ve implemented for GATE data: https://github.com/villekf/OMEGA/blob/master/source/GATE_root_matlab.cpp and https://github.com/villekf/OMEGA/blob/master/source/GATE_root_matlab_MEX.m
With ROOT 6.18.XX and newer you might run into the following error: undefined symbol: _ZN3tbb10interface78internal20isolate_within_arenaERNS1_13delegate_baseEl. This is most likely caused by the libtbb.so.2 that comes with MATLAB. Renaming the one in /matlabroot/bin/glnx64 should fix the issue.
For ROOT developers, this is the message I received from Mathworks regarding this issue:
- It seems like something within ROOT is using memory in a way that MATLAB does not expect, and that may be causing a memory leak, or corrupting memory associated with the Java Virtual Machine. This usually causes crashes when the JVM tries to do garbage collection tasks. The Customer noticed that the crashes happen less when -nodesktop is option is used, this is because the JVM is mostly related to the gui and graphics. However a crash still occurs on shutdown as the JVM is still doing some stuff. I suspect that this bug is related to bad memory management of global variables in the ROOT code/libs that MATLAB does not like. For example, we suspect that the problem arises around line 42 of TVersionCheck.h and there is a FIXME comment with a link to a bug that details how their migration to modules caused some symbol pollution. My guess is that some of the ROOT code still does this symbol pollution and MATLAB does not like it. For now it may be good for the customer to investigate the ROOT source code or try rolling back the root version substantially to where this symbol pollution does not occur.*
Reproducing the crash in MATLAB is easy by compiling and running the following code (input a number and you get the same number as output):
#include "mex.h"
#include "TVersionCheck.h"
void mexFunction(int nlhs, mxArray* plhs[],
int nrhs, const mxArray* prhs[])
{
double value = (double)mxGetScalar(prhs[0]);
plhs[0] = mxCreateNumericMatrix(1, 1, mxDOUBLE_CLASS, mxREAL);
double* output = (double*)mxGetData(plhs[0]);
output[0] = value;
return;
}