Peculiar behavior in compiled standalone

Hi there

Just working through the motions of compiled code that throws an inexplicable error. The *.m "raw" file seems to work fine, but the compiled version (suing application compiler) throws the error "left and right sides have different number of elements" precisely at a function call, e.g. function [a,b] = myFun(x,y,z). Have gone through every single line of code, every combination of inputs, the *.m file works flawlessly but the compiled version blows up.

Looked at dependencies, linted the code, checked variable types, structure, DLLs and other ancilliary functions called, nothing works. The surprising issue is that all the outputs are defined or properly initialized. The *.m file works, as said. Took the function outside (as a separate *.m file) and nothing. Bundled it inside the main code, didn't help either.

Injected specific messages at specific places within the function (to see if it blew before or after any of them, once called) but the function refuses to run on its entry point (when it throws the error).

Any ideas?

Answer 1

[Steven Lord]

Is the function in the standalone application that throws an error operating on one or more of the input arguments with which the standalone application is called? If so see "Using a MATLAB File You Plan to Deploy" on this documentation page.

You may think you're passing in a number, but you're actually passing in a char array.

x = 10

x = 10

size(x)

ans = 1×2

1 1

y = '10'

y = '10'

size(y)

ans = 1×2

1 2

[Eduardo Salazar]

Hi

The function is internal (does some processing) and does not take any input directly from the console/user. It passes one char (a file name), series of doubles and one uint8 matrix, but again, those variables are the result of internal processing by the main function prior to the function call. There are 10 similar functions, mixing variable types, and none throw an issue, bar this one.

Computations on char arrays (e.g. taking their dimension, substituting and so on) and computations on other variables are done as required to avoid the issues you mentioned.

That said, after much dissecting I now think to know where it fails. And moreover, it's seemingly OS specific.

The offending piece of code does something like this

input = 'haahhahhahahhha';
T1 = '0123456789';
T2 = 'abcdefghij';
size = numel(input);
output = blanks(size);
% Iterate over whole input vector,
% one char at a time
for k = 1:size
  output(k) = T1(T2==input(k));   % Compute and assign
end

If you run this crude example, the input variable is quite clearly re-mapped from 'haahhahhahahhha' to '700770770707770'.

This standalone works fine (without a glitch) if the compilation is done and run in Windows 10. Compiling in Windows 10 and running a test in Windows 7 (using same runtime version as compiling machine, of course) fails.

A variation of the above... which is more efficient with long char vectors that map a constrained dictionary...

input = 'haahhahhahahhha';
T1 = '0123456789';
T2 = 'abcdefghij';
repts = unique(input);
output = blanks(numel(input));
% Only iterate over uniques
for k = 1:numel(repts)
  output(input==repts(k)) = T1(T2==repts(k)); % Compute and assign into output
end

Throws the error "for colon operators with char operands, first and last operands must be char" at the "for" line. But... the only "double" here is the indexing variable in the loop (k), pik is a logical (as it should be for the task at hand) and all of the rest are chars... so it's assigning a chars to chars on locations identified by logical pik over k iterations. What is wrong with this? Needless to say, it works perfectly as *.m file and (this is the most strange thing) when run on the same computer it was compiled (OS Windows 10) but not on a different computer with a different OS (Windows 7).

Any ideas?

.

[Eduardo Salazar]

Update...

Colleague installed Matlab from scratch in a clear test machine on Win 7 Pro. 3 hour work to segregate, copy on separate media, and migrate all requisite folders and other bits to replicate the original machine (bar OS).

Attempted compilation SUCCEEDS but EXE FAILS on run.

Cleaned cache, directories and other bits on the original machine. Copied back everything (as in a clean install).

Attempted compilation SUCCEEDS and EXE WORKS on run.

Machine where it fails - OS Win 7 SP1, 16 Mb RAM, Visual C++ 2017.

Machine where it succeeds - OS Win 10 Home 20H2, 16 Mb RAM, Visual C++ 2017.

All said, another colleague took the EXE and installed the MCR on his Win 10 PC (same specs as compiling machine) and software FAILS to run.

I'm now going to do another test at subroutine-specific level to see where the issue is.