Debugger not stopping on marker

I have a short code that I have put a debug marker in, before running it, but when it gets run the code moves past the marker and stops on an error. There isn't any logic that should cause it to skip over (I can move the marker seemingly anywhere in the code before the error and it still gets skipped.)

Anybody have any suggestions?

The code looks something like the following:

for ii=200:200:30000
     command=['!systemcommand outfile.dat.' num2str(ii) ' 9.0932 0.0000 1.8288 > File.out'];
     eval(command);
     fid=fopen('File.out');

    
     for jj=1:200
        linep=fgetl(fid);                   % Crashes here.
        if length(linep) >=2    
            if strcmp(linep(1:5),'T    ')        
                T=[T;str2double(linep(6:end))];
            elseif strcmp(linep(1:6),'taubeg')
                t=[t;str2double(linep(10:end))];
             end
        end
     end  
    fclose(fid);
end

[Rik]

Just in case it matters:

% replace this
command=['!systemcommand outfile.dat.' num2str(ii) ' 9.0932 0.0000 1.8288 > File.out'];
eval(command);
% with this
command=sprintf('systemcommand outfile.dat.%d 9.0932 0.0000 1.8288 > File.out',ii);
system(command);

You should also generally test if fopen succeded (by checking if fid>0).

None of this should be causing the issue with the break points, but they will make your code more robust.

[Bob Thompson]

What's the difference between the two command generations? I feel like I've used both in different methods, but never looked into what the difference is.

[Jan]

@Bob Thompson: See TUTORIAL: How and why to avoid EVAL

[Bob Thompson]

Hmm, ok. Most of the tutorial focuses on why eval is bad for dynamically created variables, whereas I'm trying to create and execute a system command.

Are you trying to highlight to me the portions related to speed, reliabilty, and security? How is system different in that regard?

[Rik]

Why use eval when you can avoid it? eval will never be faster and will always call attention. I would classify it as a code smell. It might not actually make a big difference here, but it will be interpreted as a sign that you either don't know or don't care about good coding practices.

[Jan]

@Bob Thompson: Avoiding EVAL is a good programming practize, not only in MATLAB, but as well in other interpreted langauges. MATLAB's code analysis cannot estimate the side effects of an EVAL command and therefore this command can have side-effects on the JIT acceleration although no variables have been defined dynamically.

Answer 1

[Image Analyst]

Are you sure the file is saved before you try to set the breakpoint? I notice that if you stop at a break point, edit the code, and then try to set another breakpoint, it won't let you. And you can't save it while it's running or stopped at a breakpoint. You have to stop running completely, then save it, then set your breakpoint.

[Bob Thompson]

The breakpoint was set without the code being active.

I ran the code, found I had an error (which automatically exited the code run), and then set the breakpoint because I wanted to capture the variables before the crash. Running the code a second time without changing anything and it skipped over the breakpoint, hit the error, and quit. The only way I can get it to 'pause' while running is to set the option to 'pause on errors' in the run options.

[Image Analyst]

Call tech support and they'll do a screen-sharing session with you.

[Bob Thompson]

Thanks, I'll look into that.