Matlab doesn't "Pause on Error" till Infinite recursion

Hello,

for a project I am working on I have to rewrite a .m-file. As it is quite complex (at least for me) I move forward by running the edited script, getting the next error message, fixing the issue and reapeat. This worked fine for my last few projects, however with this, it's different.

When Matlab hits a line it can't execute (e.g. a function that is not in the file path), it throws an error (as expected)...

Undefined function or variable 'Output_data'.

Error in wPLI_openfield (line 237)
        data.trial{k} = Output_data((j:(k*10000)),:)';

...but won't stop computing for a few minutes or so (haven't timed it yet, maybe 2 - 4 minutes?). After that I get the following error message:

Out of memory. The likely cause is an infinite recursion within the
program.

Error in fileparts (line 40)
elseif ~isrow(file)

The recursion unlikely comes from the script (had the same problem with different m.-files) i am editing. I guess it has to be a more basic problem of Matlab or its core functions. But honestly, I just don't know.

As this is quite annoying and I don't know where it comes from, I hope some of you guys can help me with this issue. I already tried reinstalling everything twice.

I'm using Matlab2018a 9.4 on my Windows 10 Home 64 bit system.

[Adam]

Did you strip your path back to the minimum (just Mathworks folders plus a single folder for your own code) and see if you still get the problem?

Answer 1

[Steven Lord]

Try setting a breakpoint on line 237 of wPLI_openfield. When MATLAB reaches that point, it will enter debug mode and the prompt will change to K>>. At this point, check that the fileparts and isrow functions that are being called are the ones written by MathWorks.

which -all fileparts
which -all isrow

This will check if there are fileparts or isrow functions in a directory that wPLI_openfield (or something called before wPLI_openfield) changes to with cd or adds to the path with addpath (but that the code normally changes away from or removes from the path before returning to the Command Prompt) and so were not "visible" to MATLAB when you checked before.

If that doesn't show anything, Walter may still be correct that there is a third-party toolbox interfering. To check this, can you show the list of products displayed when you execute the ver function? That's not foolproof (not all third-party toolboxes do what's needed to show up in ver, but it might show something that we've seen before and recognize as a potential cause.

[Mark Schmid]

Thanks for the advice.

In the last two hours I played around with some minor code changes in wPLI_openfield (regarding the 'Output_data' variabel) and haven't had any issues with Matlab going into infinite recursion.

I tried going into debug mode nonetheless and checked for the fileparts and isrow functions...

K>> which -all fileparts
C:\Program Files\MATLAB\R2018a\toolbox\matlab\iofun\fileparts.m

K>> which -all isrow
C:\Users\MARK\BA\MATLAB\fieldtrip-20191022\compat\matlablt2010b\isrow.m
isrow is a built-in method                                                     % Shadowed string method
C:\Program Files\MATLAB\R2018a\toolbox\matlab\datatypes\@categorical\isrow.m   % Shadowed categorical method
C:\Program Files\MATLAB\R2018a\toolbox\matlab\bigdata\@tall\isrow.m            % Shadowed tall method
C:\Program Files\MATLAB\R2018a\toolbox\distcomp\parallel\@distributed\isrow.m  % Shadowed distributed method
built-in (C:\Program Files\MATLAB\R2018a\toolbox\matlab\elmat\isrow)  

...as well as for the Matlab version.

K>> ver
-----------------------------------------------------------------------------------------------------
MATLAB Version: 9.4.0.813654 (R2018a)
MATLAB License Number: 886885
Operating System: Microsoft Windows 10 Home Version 10.0 (Build 18362)
Java Version: Java 1.8.0_144-b01 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
-----------------------------------------------------------------------------------------------------

A few moments after I ran the 'ver', the error message appeared again (still in debug mode).

Out of memory. The likely cause is an infinite recursion within the
program.

Error in fileparts (line 40)
elseif ~isrow(file)

It seems like Matlab is still computing something (fan is still quite loud + CPU usage of Matlab is at about 45% according to task manager), even though it shouldn't because it reached a breakpoint (or am I wrong about this?).

Something different that caught my attention in the last days since I had the recursion issue is that Matlab can't find wPLI_openfield in the current directory/the added paths. Even if add the path to the folder in which the .m-file is located or I run it and rerun it again it takes a moment and then shows me following pop up.

[Mark Schmid]

Additional info:

As you might suggest the problem is a third party toolbox interfering with basic Matlab functions, here's a list of all the third party toolboxes I (knowingly) use for my project:

• Chronux Toolbox (http://chronux.org/)
• Fieldtrip Toolbox (http://www.fieldtriptoolbox.org/)
• EEGLab (https://github.com/sccn/eeglab)
• Multivariate Granger Causality (mvgc) Toolbox (https://users.sussex.ac.uk/~lionelb/MVGC/html/mvgchelp.html)

For an earlier project I also set up nVidia CUDA 9.0 alongside the Microsoft Visual Studio 2015 C++ Compiler.

[Guillaume]

As a simple experiment, remove these toolboxes. In particular, I'm sure I remember somebody reporting problems here with either the fieldtrip toolbox or eeglab (can't remember which) and indeed the issue was that the toolbox had its own isrow.

[Walter Roberson]

C:\Users\MARK\BA\MATLAB\fieldtrip-20191022\compat\matlablt2010b\isrow.m

That's the problem. It looks like your code might be adding that to the path. You should probably rename that file to something like isrow_unused.m so it does not get invoked. But look at what other files are in the same directory, as they could also cause problems.

[Steven Lord]

And you probably want to alert the authors / maintainers of the Fieldtrip Toolbox, as from the path I'm assuming that's what installed this. They may want to add a check to whatever adds that "compat" directory to the path to only add it when the user is running a sufficiently old release of MATLAB.

[Walter Roberson]

Some of the toolboxes have installation instructions that talk about installing the compatibility directories or not, but most people do not look at those instructions.

[Mark Schmid]

Thank you guys for helping me out!

I've checked the compat directory and indeed there were functions messing with built-in functions in Matlab. My Matlab version is sufficient and I don't need any of the compat functions so I removed the directory all together.

The README files suggested that there is an explanation when and why to add the compat directory to the Matlab path, but as I got the toolbox from a coworker alongside the script I'm currently editing I haven't paid attention to the installation and setup details. My bad.

I've tried around with Matlab and it seems like the issue is fixed.

Answer 2

[Walter Roberson]

There are some third-party toolboxes that define isrow() and that interferes with MATLAB. Check

which -all isrow

What you see should start with a bunch of line similar to

built-in (/Applications/MATLAB_R2019b.app/toolbox/matlab/elmat/isrow)
built-in (/Applications/MATLAB_R2019b.app/toolbox/matlab/elmat/@cell/isrow)                % cell method
built-in (/Applications/MATLAB_R2019b.app/toolbox/matlab/elmat/@char/isrow)                % char method

You should not see any .m files listed until

/Applications/MATLAB_R2019b.app/toolbox/matlab/timefun/@datetime/datetime.m                % datetime method

and a few others that are obviously from Mathworks.

What you will probably see instead is the first one being a .m from some third party code. You will need to use pathtool to locate the directory that code is in, and move it to the end of your MATLAB path, and save.

[Mark Schmid]

Hey thanks for the advice,

I tried

which -all isrow

and this is what I get:

built-in (C:\Program Files\MATLAB\R2018a\toolbox\matlab\elmat\isrow)
isrow is a built-in method                                                     % string method
C:\Program Files\MATLAB\R2018a\toolbox\matlab\datatypes\@categorical\isrow.m   % categorical method
C:\Program Files\MATLAB\R2018a\toolbox\matlab\bigdata\@tall\isrow.m            % tall method
C:\Program Files\MATLAB\R2018a\toolbox\distcomp\parallel\@distributed\isrow.m  % distributed method

Seems to me they're all coming from Mathworks though.

I've found a solution searching for a way to fix Matlab being slow after running a script which takes up much of the memory (https://de.mathworks.com/matlabcentral/answers/438806-why-is-matlab-slow-with-large-objects-in-the-workspace-even-when-ram-is-not-limited).

The answer was simply hiding the workspace window and this seems to have fixed my initial issue as well. Probably there's something going on with the display of the used variables.

[Mark Schmid]

Okay I'm back to square one, as it throws the same error message again after running the script. This time I haven't had an error in my m.-file. It just calculates a while, then I get this:

Out of memory. The likely cause is an infinite recursion within the
program.

Error in fileparts (line 40)
elseif ~isrow(file)
 
Out of memory. The likely cause is an infinite recursion within the
program.

Error in fileparts (line 40)
elseif ~isrow(file)
 
Out of memory. The likely cause is an infinite recursion within the
program.

Error in fileparts (line 40)
elseif ~isrow(file)
 
Out of memory. The likely cause is an infinite recursion within the
program.

Error in fileparts (line 40)
elseif ~isrow(file)
 
Out of memory. The likely cause is an infinite recursion within the
program.

Error in fileparts (line 40)
elseif ~isrow(file)
 
Out of memory. The likely cause is an infinite recursion within the
program.

Error in fileparts (line 40)
elseif ~isrow(file)
 
Out of memory. The likely cause is an infinite recursion within the
program.

Error in fileparts (line 40)
elseif ~isrow(file)

Even though my command prompt is active again (>>), it keeps throwing the same error. Like Matlab is stuck in the infinite recursion and every time the error occurs, it just clears the memory and starts all over again untill a few moments later the error occurs again. This happens about 6 to 7 times. It's very strange, I do not have a single clue what it could be and how to fix it.