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: and

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 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;


We didn’t have modules enabled (by default) in 6.18, so the comment my the MATLAB devs doesn’t look relevant. I also totally don’t see how TVersionCheck has anything to do with memory. Let alone with MATLAB. My suspicion is that TVersionCheck is a red herring, and the actual issue is with initializing gROOT (which it turn opens libCling and its JIT). A backtrace of a crash could help.

Short of actually debugging this I don’t think we will make progress. I don’t have MATLAB and don’t expect to be able to spend time on this. I am happy to help anyone who wants to debug this.

Cheers, Axel.

Here are some crash dumps in case they will be of use: (22.5 KB)

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.