I recently consulted at a client who uses R2010a and compiles his code for distribution. Debugging compiled code is often tricky, since we do not have the Matlab desktop to help us debug stuff (well, actually we do have access to a scaled-down desktop for minimal debugging using some undocumented internal hooks, but that’s a topic for a separate article). In my client’s case, I needed to debug a run-time error that threw an exception to the console:

Error using strtrim
Input should be a string or a cell array of strings.
Error in updateGUI (line 121)

Sounds simple enough to debug right? Just go to updateGUI.m line #121 and fix the call to strtrim(), correct?
Well, not so fast… It turns out that updateGUI.m line #121 is an empty line surrounded on either side by one-line comments. This is certainly not the line that caused the error. The actual call to strtrim() only occurs in line #147!
What’s going on?
The answer is that the Matlab compiler has a bug with comment blocks – lines surrounded by %{ and %}:

15   %{
16       This is a comment block that is
17       ignored by the Matlab engine,
18       and causes a line-numbering
19       error in the Matlab compiler!
20   %}
21 
22   a = strtrim(3.1416);  % this generates an error

In the example above, the 6-line comment block is ignored as expected by the Matlab engine in both interactive and compiled modes. However, whereas in interactive mode the error is correctly reported for line #22, in compiled mode it is reported for line #17. Apparently the compiler replaces any block comment with a single comment line before parsing the m-file.

The workaround is simple: count all the block-comment lines that precede the reported error line in the original m-file, and add that number to the reported line. In the example above, 17 + (6-1) = 22. Note that the source code could have multiple block-comments that precede the reported line, and they should all be counted. Here is a basic code snippet that does this parsing and opens the relevant m-file at the correct location:

% Read the source file (*.m)
str = fileread(filename,'*char');
% Split the contents into separate lines
lines = strtrim(strsplit(str',10));
% Search for comment block tokens
start_idx = find(strcmp(lines,'%{'));
end_idx   = find(strcmp(lines,'%}'));
% Count the number of block-comment lines in the source code
delta_idx = end_idx - start_idx;
relevant_idx = sum(start_idx < reported_line_number);
total_comment_block_lines = sum(delta_idx(1:relevant_idx));
% Open the source file at the correct line
opentoline(filename, reported_line_number + total_comment_block_lines);

This code snippet can fairly easily be wrapped in a stand-alone utility by anyone who wishes to do so. You'd need to generate the proper full-path source-code (m-file) filename of course, since this is not reported by the deployed application in its error message. You'd also need to take care of edge-cases such as p-coded or mex files, or missing source-code m-files. You'd also need to parse the input parameters (presumably filename and reported_line_number, but possibly also other inputs).
This is another example of a bug that does not officially exist in Matlab's public bug parade ^[1] (at least, I couldn't find it). I've reported other such undocumented bugs in previous articles (here ^[2] and here ^[3]). Please don't start another comments tirade on MathWorks' bug-publication policies. I think that issue has already been discussed ad nauseam.
Update: according to Tom's comment ^[4] below, this bug was apparently fixed in R2012b.
Another related bug related to block comments is that at least on some Matlab releases (I haven't tested properly to determine which releases), block comments are NOT properly ignored by the Editor's publish functionality. Instead, at least on those releases where the bug occurs, publishing code that includes block comments parses the block's contents as if it was runnable code. In other words, publish treats %{ and %} as one-line comments rather than as tokens marking the ends of a block comment.

6 Comments To "Matlab compiler bug and workaround"

#1 Comment By Ty Cumby On January 28, 2015 @ 13:09

#2 Comment By Yair Altman On January 28, 2015 @ 13:14

#3 Comment By Arthur On January 29, 2015 @ 09:35

#4 Comment By Yair Altman On January 31, 2015 @ 11:43

#5 Comment By Tom On February 2, 2015 @ 06:37

#6 Comment By Yair Altman On February 2, 2015 @ 06:39