Invalid character in .m file after compiling with MCC

I've been pulling my hair for the last 7 hours with an issue I really can't seem to find a solution to or even an explanation of how it is occurring.

I'm currently working on developing a standalone application which among other things uses Matlab slaves to convert files (it starts new Matlab processes which execute certain functions). Here is where the issue occurs. If I run the application from Matlab (without compiling a standalone) it works fine and all the slaves work as expected. However, when I compile a standalone it does not work. The different situations I've tried are:

• Using the master instance of Matlab as well as one additional slave to convert two files (one file for each instance of Matlab). In this case the master instance can successfully convert the file it is given but the slave stops at the following error: Invalid text character. Check for unsupported symbol, invisible character, orpasting of non-ASCII characters.
• Using only the master instance of Matlab to convert two files. In this case the master instance stops at the same error as above.
• Using only the master instance of Matlab to convert ONE file. This works as intended.
• Using the master instance as well as a maximum amount of slaves (number of cores) to convert 8 files. In this instance the master instance succeeds and the rest have the same issue as before.

It seems to be concentrated around the specific function I am trying to run on the slaves. However, this should mean that the master instance shouldn't be able to execute the function either. To tackle the problem so far I've tried:

• Rewriting the entire function (no copying text at all) to get rid of potential hidden characters.
• Rewriting the entire calling parent function.
• Including the affected function as "files installed for the end user" and making sure the application changes to that directory to find the unspoiled .m file.
• Converting the .m files from ANSI to UTF-8 and ISO-8859-1 encoding
• Changing the default encoding for Matlab at startup to UTF-8 and ISO-8859-1

Nothing of the above works at all. There also is no issue at all using the system function in any other state of the application for e.g. compressing files. The entire application works except for this "small" or not small issue.

Any ideas whatsoever?

[Walter Roberson]

Could you talk more about what "converting" files means?

"ncluding the affected function as "files installed for the end user" and making sure the application changes to that directory to find the unspoiled .m file."

That will not help, as compiled executables can never execute .m files.

Is there any relationship between the names of the files being worked with and the name of the function that is failing?

If you save files, where do you save them?

[Anton Kullberg]

Basically what's happening is that the user selects a directory which contains MDF files. The application then loads each MDF file separately, selects specific data from them and saves them as MAT files in the same directory.

The names don't have any relationship whatsoever. I've also tried using completely different data files with no success. Also: the files that are failing can be successfully converted if only one file is to be converted.

I also forgot to add that using the "for_testing" .exe works fine and as intended.

_______________

Additionally: I'm starting a matlab "slave" with a call as follows:

cmd1 = ['matlab -minimize -nosplash -r '];
cmd2 = ['cd(''' BaseDir ''');'];
cmd3 = ['convertMDF2MATBatch(' num2str(BatchNr) ', ' num2str(useZOH) ', ' num2str(convert2SI) ');'];
status = system([cmd1 '"' cmd2 cmd3 'quit;" &']);

Where BaseDir in this case would be the directory where the convertMDF2MATBatch is located. The reason why I want to change directory to this location is because the convertMDF2MATBatch function saves and loads temporary files. I don't want them visible for the typical user, hence the cd.

Answer 1

[Anton Kullberg]

I managed to fix the issue by simply not starting matlab slaves in the way mentioned. Instead, I compiled an executable of the function I was trying to call from the slaves. Using this method, I can just use a system call as such:

system(['convertMDF2MATBatch ' num2str(BatchNr) ' ' num2str(useZOH) ' ' num2str(convert2SI) ' &']);

This spawns a CMD instance where the convert executable is then run instead of spawning a new MATLAB instance. I'm guessing the issue was that I was spawning new MATLAB instances (not the MCR) which were trying to use the compiled functions, which obviously doesn't work.

It's unclear if this behaviour is intended but isn't it reasonable that a compiled application, when making a MATLAB system call, should spawn new instances of MCR and not of MATLAB itself?

I'm guessing another solution (if you want to spawn MATLAB instances from a compiled application) is to include the .m files as files installed for the end user; then when you spawn a MATLAB instance, change the directory to the installation path and run everything from there. However, this requires MATLAB to be installed on the target computer, which is what we're trying to avoid.