A short while ago, I was working at a client’s location on some project, when a very strange thing happened: when editing an m-file in the Matlab editor, the mlint process (the one that reports errors and warnings on the right-hand side of the editor) suddenly decided that it has had enough with this specific file. It labeled the entire file as red, meaning that it has errors that prevent it from being run, although as far as we could both see the file was valid and had no syntax errors and actually ran fine.
Here’s a screenshot of the message that mlint reported in the editor:
Mlint’s confusion would not have bothered us if it were not for a seemingly-related issue: When we tried to save the file, the Matlab editor would only allow us to save the file under a different name. When we attempted to restart Matlab, the same behavior repeated for this file, and we could not proceed with our actual work, modifying and saving our m-file.
Not easily intimidated, I tried saving the file under a different name in the editor, then renaming it back outside Matlab. No good, same problem.
MLintFailureFiles or: yet another use for prefdir
The clue that eventually led to the fix was that somehow Matlab remembered the “faulty” state of the m-file even after I restarted Matlab. Matlab likes to store persistent cross-session information in a single folder, which is the user’s prefdir folder. I have used this to my advantage only a few weeks ago, when I explained how to use the stored editor state file that is stored in that folder.
My hunch was that Matlab might store the mlint’s “faulty” m-file state somewhere in there. I didn’t have to look very far: one of the files most recently modified had the tell-tale name of
MLintFailureFiles. This turns out to be an empty file that contains the full pathname of the “faulty” m-files, one file per line.
The fix turned out to be very easy: simply remove my file from the MLintFailureFiles file (or delete MLintFailureFiles entirely) and restart Matlab. Problem solved – everything back to normal. Resume breathing.
Undocumented? well, not exactly
I then went back to the suggestion in the mlint message and true enough I found related information in the documentation, at the bottom of the doc-page for using mlint. This is from R2008a’s doc page:
About M-Lint and Unexpected MATLAB® Termination
Under some circumstances, when you are editing an M-file, M-Lint can cause the MATLAB session to terminate unexpectedly. The next time you start MATLAB, it displays the following message and disables M-Lint for the M-file that was open in the editor when MATLAB terminated.M-Lint caused your previous MATLAB session to terminate unexpectedly. Please send this message and file name to The MathWorks. See "About M-Lint and Unexpected MATLAB Termination" in the MATLAB documentation for details.
If you want, while waiting for a response from The MathWorks™, you can attempt to reenable M-Lint for the file by following these steps:
- In the Editor, reopen the file that you were editing when MATLAB terminated.
- Remove the lines of code that you believe M-Lint could not handle.
- In a text editor, open the MLintFailureFiles file in your preferences directory. (This is the directory that MATLAB returns when you run prefdir.)
- Save and reopen the M-file.
As you can see, this is not very helpful because it’s missing the step of actually editing (or deleting) the MLintFailureFiles file.
A Matlab user has even created a utility on the File Exchange that simply deletes this file, basing his work on the first note above.
The second note indicates that the problem (and workaround) occur in Matlab releases R2008a-R2010b, and indeed the above-mentioned issue (and workaround) can no longer be found in the latest docs (as far as I could see). However, even if this issue (and MLintFailureFiles) may no longer be relevant in the latest Matlab releases, we may still see MLintFailureFiles in our prefdir, because the prefdir contents are automatically copied from the previous release whenever we install a newer Matlab release.