nested function call using inputname crashes matlab

I'm trying to develop an efficient pipeline execution framework : more details here

Because of the fact that there are no pointers in matlab, I am relying on inputname() for grabbing the input, output variable names, and function names, along with using f handles. I'm experimenting with different (command line) user interfaces for this purpose, and currently settled on this :

a = intel_pipe;
a.f(a.o(o1,o2),@f1,a.i(i1,i2));

here i1,i2 are input variables, o1,o2 are output variables, and f1 is a function.

 function i_vars = i(obj,varargin)
   exec_comm_script;
   i_vars = obj.add_vars(args);
 end

 function o_vars = o(obj,varargin)
   exec_comm_script;
   o_vars = obj.add_vars(args);
 end

exec_comm_script.m :

   strerror = 'arguments cannot be expressions';
   nvarargs = length(varargin);
   nconstargs = 1;
   args = zeros(1,nvarargs);
   for ii=1:nvarargs
  varn=inputname(nconstargs+ii);
  if isempty(varn)
    error(strerror);
  end
  args(ii)=varn;
   end

When I execute this, it works fine if debugging, but crashes unfailingly if not debugging. When, however, I paste the contents of the script into both the functions, (duplicating the content, it works fine.

What's going on?

------------------------------------------------------------------------------

Note : As expected I am using evalin and assignin here, but I really don't see any way to do this kind of thing other than to use matlab's reflection abilities. The important thing here is that this is meant to be used with large data that takes time to compute. Hence I cannot afford to keep copies of data, and hence evalin('base','...'); is a must.

I am also checking for empty names and disallowing expressions in the input and output arguments because it defeats the purpose of deferring execution in input, and is invalid anyway in the output.

You could say I should be asking the users to enter variable name strings in the first place, but then it would become my responsibility to check if the variable exists etc, instead of the interpreter's. Plus it's really ugly and irritating for the user.

Answer 1

[Philip Borghesani]

You have found a bug in the MATLAB jit. This code works correctly if you enter feature accel off from the command line first. It will be fixed in a future version of MATLAB.

That said this technique is a bad idea and should not be needed. By utilizing of MATLAB's copy on write behavior and in-place optimization (see Loren's Blog) it should be possible to avoid unnecessary copies of large variables.

If you publish code samples that seem to be too expensive to do without evaling in base I expect contributors here can assist in specific optimizations that will not require use of inputname and evalin.

A second reason to avoid inputname is that it can be a very slow function because it must introspect into the currently executing stack frame.

[Milind]

Thanks, that worked. I did not notice any large increases in running time, but requires more testing with longer-running functions.

I did consider using the copy-on-write feature, but how would I detect updates to variables?

Answer 2

[Sean de Wolski]

If the crash is not happening in debug mode, this implies that somewhere an event is not being flushed properly. Add a drawnow in there in a few places, this is implicitly called when you're stopping in debug mode.

[Milind]

Interesting, did not know that. Didn't work however, even though I added a drawnow the moment I land in a.f();

Will keep tinkering with it though.

Answer 3

[Adam]

'This command can be used only inside the body of a function.'

from the help page for inputname:

doc inputname

I'm not sure about the rest of what you are doing, but that function takes input names within the scope of a function and the names are those of the variables in function scope, not the names of the variables in the workspace from which they were passed in which is something you should never be wanting to get hold of anyway.

[Milind]

That directly contradicts what I keep seeing in my usage : inputname(n) gives me the name of the nth input argument in the caller's scope.

And if not that, how would I do what I'm trying to do here?

[Adam]

Ah yes, that is true actually. I didn't read that far through the help and assumed there wouldn't be a function to do that.

I guess you can use it for that then in a function though it sounds like dodgy programming practice to be interrogating the names of variables in the calling workspace. They should never be the business of a function that is being called.

[Titus Edelhofer]

Generally speaking: you are right. inputname is usually interesting when writing a display method for your own objects (classes). The output of a display then is e.g.

A = 
  someObject

That's where the "A = " might add some "niceness". It's usually not used to rely on it in the sense that you work with variables (by name) from the calling workspace.

Titus