Errors and crashes and namespace inadequacies, just a typical day.

May 11, 2012 at 5:41 pm (a namespace, errors in error handling, my kingdom for a namespace)

I mostly work on MATLAB R2010a because there is a particular library (which is the only reason I am forced to use MATLAB) that only builds on 32-bit, and R2010a was the last 32-bit release.

I recently encountered a couple of bugs in the MATLAB interpreter and wanted to check if they had been fixed in future versions.

Well, launching R2011B, I find a lot of stuff not working. Hell, I try to “edit” a file and it returns me:

>> edit crashme.m
/home/peterm/eyetracking/matlab-bugs/crashme.m
Error using edit (line 66)
Not enough input arguments.

Now, that’s really weird, because obviously I supplied an argument to “edit.” What the hey? I try editing some other files, it works okay. I try invoking edit like edit(‘crashme.m’) and it still fails. Not enough input arguments?

Usually as a programmer there’s a little mental hurdle you have to leap over to even begin to think maybe the problem is with the system and not with what I’m doing After all, I’m just sitting here banging at the keyboard, and presumably if I’ve selected reliable tools, the likelihood that I banged a wrong button ought to be higher than the likelihood that my tools are busted.

Years of experience has shown that when dealing with MATLAB that little mental hurdle does me no good. So here I go debugging MATLAB’s own code.

Now all I know is it failed in line 66 of “edit.m”, which is preceded by this many endifs (uh, the
|| operator, have you guys heard of it?)

    57	                                end
    58	                            end
    59	                        end
    60	                    end
    61	                end
    62	            end
    63	        end
    64	    end
    65	catch exception
    66	    throw(exception); % throw so that we don't display stack trace
    67	end

AAAAAAARGH. NO. Do. Not. Do. This.

As I said in previously the entire purpose of exceptions is to propagate out information about the manner of failure — not to disguise the manner of failure behind a lie. I don’t give a shit if it’s an internal function. Propagate out the actual information so I don’t have to break out the debugger on your busted code.

Well, now the only recourse is to reach for the debugger. This is risky: after all, the mere act of bringing up a file in the editor (as the MATLAB GUI does whenever a breakpoint is reached) might very well call “edit” somewhere along the line, so if I set a breakpoint in “edit”, it might go chasing up its own tailpipe.

So I save my work before proceeding.

Setting a breakpoint there on line 66, I find:

K>> edit crashme.m
/home/peterm/eyetracking/matlab-bugs/crashme.m
66      throw(exception); % throw so that we don't display stack trace
K>> getReport(exception)

ans =

Error using sprintf
Not enough input arguments.

Error in message (line 8)
string = sprintf(varargin{:});

Error in edit>openEditor (line 234)
            errMessage = message('MATLAB:Editor:EditorInstantiationFailure');

Error in edit>openWithFileSystem (line 458)
    openEditor(pathName);

Error in edit (line 51)
                        if ~openWithFileSystem(argName, ~isSimpleFile(argName))


K>> 

OH COOL. IT’S AN ERROR YOU HAD WHILE TRYING TO PRINT AN ERROR MESSAGE.

Ah, we see that the original error, which at first claimed nonsensically to be a case of “not enough arguments to edit” was really “not enough arguments to sprintf.” Interesting. And sprintf was called by… Ah! What we have here is yet another goddamned namespace problem. The call to message is actually reaching my function:

K>> which message
/home/peterm/eyetracking/code/graphics/message.m

Are you getting why you should not funnel exceptions yet? If the people at The Mathworks had simply not written a try/catch clause there, I would have seen the cause of the problem without doing anything like rolling up my sleeves.

It seems my “message.m” is shadowing some other “message.m.” Now, I’m reasonably careful. When I originally chose the function name “message”, I looked at the landscape of MATLAB’s stupid global search path (because when nothing inhabits anything like a namespace, you have to tread carefully) and found that “message” is only used by a couple of toolbox methods that should be safe as long as MATLAB’s method dispatch works how it’s supposed to (ha):

>> which -all message
/Applications/MATLAB_R2010a.app/toolbox/shared/spcuilib/@uiservices/message.m                 % uiservices method
/Applications/MATLAB_R2010a.app/toolbox/shared/filterdesignlib/@FilterDesignDialog/message.m  % FilterDesignDialog method

Of course I should have expected that Mathworks would leave no pronounceable string of letters available to users, and ensure that anyone’s code would mysteriously break if they had thought to name something “message.” In 2011b, I find,

K>> which -all message
/home/peterm/eyetracking/code/graphics/message.m
/usr/local/matlab11/toolbox/matlab/lang/message.m % Shadowed

Inspecting “message.m” reveals that it’s a newly added function and that it’s for internal use only. If you had previously written something called “message”…. tough luck. Nor warnings or nothing, just mysterious failures you have to debug.

Mathworks, what on earth are you doing putting more pollution in the global namespace if you supposedly implemented packages back in r2008a? Didn’t you declare back in 2009 that there would be a package you would be moving your internal shit into?

(It’s not been done because the namespace mechanism barely works, is my best guess.)

Anyway, after moving my “message” out of the way…. I can finally open the file in my editor. Beats me why “edit” was choking on giving me an error message in the first place, since it completed successfully. And yeah, the runtime bug I found is still there. Check this out if you want to crash your Matlab:

function crashme()
    crash1();

    function crash1()
        
        x = crash2();
        x();

        function x = crash2()
            x = evalin('caller', '@() eval(''1'');');
        end
    end
end

About these ads