Bug in Persistent variables? Simulink M-function

I am unable to initialize a Persistent variable. Here's a snippet of code in a Simulink M-function which does not actually set 'a' no matter what I do:

persistent a
if isempty(a)
    a = 1;
end

Either printing out 'a' or evaluating 'a' gives

a=[]

...NOT a=1 as it should.

It doesn't matter what the variable name is, or what I try to set it to, or how many variables there are. This bug happens with two different sets of Persistent Variables.

However, oddly, later on in the SAME M-function, I do another persistent declaration using the exact same method and there initialization DOES work.

I tried this in both R2016a and 2017b

What is going on?

[John Pryce]

This bug exists. My "main program" is a function with input arguments and the crash occurs some levels down inside an a function that is called by fzero(), so isolating the error was tricky.

I confirm what John says "It doesn't matter what the variable name is, or what I try to set it to". Further:

• If it crashes and I immediately re-run with the same inputs it always goes on crashing.
• If I then run with different inputs it may work correctly.
• If after doing something else I re-run with the original inputs that caused the crash it may work correctly.
• Changing the layout of code, or changing nearby code, may change it between working and crashing. E.g. I originally had if nargin>4, it = it0; end below, and changing it to what's written cured the problem – so I thought! But it reappeared with other inputs.
• Stepping through in the debugger, with argument it0 absent so nargin>4 is false, I found that though it skipped the it = it0; statement, it nonetheless changed the value of it to an unpredictable value (e.g. 165) while going from if to end.
• Once past this perilous initialisation, it seems it behaves as it should do.

The piece of code in question is

function [x,xp,it1] = searchAndInterp(tt,xx,xxp,t,it0)
% some comments
persistent it %Seems most economical way to implement this
itbefore=it %!!!DEBUGGING
if nargin>4
  it = it0;
end
if isempty(it), it=1; end
itafter=it %!!!DEBUGGING
%...

That evidence should help locate where in the compiler the error is located. I have a file of relevant command window output but can't see how to attach it.

I'm using

-----------------------------------------------------------------------------------------------------
MATLAB Version: 9.5.0.944444 (R2018b)
Operating System: Mac OS X  Version: 10.14.4 Build: 18E226 
Java Version: Java 1.8.0_152-b16 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
-----------------------------------------------------------------------------------------------------

[John]

Mathworks, any comment?

Odd indeed that it's still not fixed.

They never responded to the original bug either.

[amin ya]

I can confirm that this is a bug. I am on Matlab 2019b Update 3

[John]

Amin, it's sad to see this major bug still exists after 2 years.

There has been no reply from Mathworks -- Mathworks, are there any plans to resolve this bug?

Answer 1

[John]

Okay, now I'm certain it's a BUG. The code WILL -- or will NOT -- properly initialize a variable depending on where it is located in the function, and what is around it. Even if the init is unrelated to the surrounding code.

Eg

<code 1>
persistent a
if isempty(a)
    a = 1;
end
<code 2>
<code 3>

might NOT work, but

 <code 1>
 <code 2>
 persistent a
 if isempty(a)
     a = 1;
 end
 <code 3>

WILL work.

The surrounding Code 1, 2, 3 are completely unrelated to the variable 'a'. Likewise, an init that DID work at a certain section will no longer work if it is moved.

Unfortunately, I cannot make the code work in places that I need it to, as it seems to be random why it works or is buggy.

Mathworks -- any response?

[Youssef Ismail]

I also have the same problem has it been solved?

[John]

Not resolved to my knowledge, unfortunately. You could try my workaround of finding a code order that may work for your code.