Load command stuck in compiled matlab function. No errors, function just times out.

Hello,

I'm baffled at the moment... I have a (large) simulation that I've compiled using the R2013b MCC on a Linux platform. From the logs, it starts correctly, but execution seems to get stuck in the

load([filename '.mat'])

command. There is no error reported, but the simulation times out.

I've verified that the script works uncompiled with the same input parameters, loaded .mat file, and included paths (using the -a switches for mcc). Note that filename is an absolute (not relative) path, that I've verified.

I've searched around, and I've seen that there are issues if you try to load in ascii files, but I don't think this is ascii... I have a separate script that executes

save([filename '.mat'])

at the end (with no -ascii switches). So doesn't this avoid the ascii issues? I'm practically begging for thoughts here... I'm by no means a Matlab novice, but I am out of ideas. Without an error message, I don't have direction...

Thoughts? Thanks, Mike

[MikeStein]

I did some further testing and did narrow down the problem scope, but I'm even more perplexed...

I wrote a very simple script:

function compiledScript(filename, in2)

%%Handle deployed setup:
global MPI_COMM_WORLD;

if isdeployed
    in2 = str2num(in2);

    % Setup MPICH:
    MPI_Init();
    myID = MPI_Comm_rank(MPI_COMM_WORLD) + 1
end

%%Initial test script (verified working)
whos
load(['../../' filename])
whos

% Test loaded function handle from above load: (verified working)
callMe(in2, 3) 

%%Try simply loading the same matlab file for the big sims:
filename = '/workspace/workgroup/data/MedJTOpath_initialTest.mat'
load(filename)
whos

% Close MPICH:
if isdeployed
  MPI_Finalize();
  mex_exit();
end

return

Using this, I tested the following cases: -Compile this, not including any of the path dependencies of the latter loaded variables. While I got all sorts of warnings that Matlab didn't know how to interpret the loaded objects when the load executed, all the variables were quickly loaded to the workspace and just converted to structs. Good!

- I commented the latter load code, and added the path dependencies for the second loaded file (which wasn't loaded in this case). No issues... the first statements executed in ~2:30 rather than 0:36 when the extra path dependencies weren't included on the mcc call. Good.

So, from the two cases above, I seem to be able to compile scripts with the necessary path dependencies, and I seem to be able to efficiently load in the .mat file.

BUT, when I load the very same path dependencies and execute the latter load command, the same freeze occurs and the script times out with no errors. I gave it 59:00 to see if it was just taking a little longer, but still nothing...

Ideas? If I add path dependencies and I don't get errors in the mcc output, shouldn't I be good with that code?

I'm open to testing other things if you think that would shed more light on anything. -Mike

[MikeStein]

I tried saving the .mat file with the '-v7.3' flag to see if that helped, but it didn't. Same behavior. Thoughts??? Please

Answer 1

[Image Analyst]

I deal with this all the time. Not hanging, but filenames in compiled apps. It should throw an exception that the file is not found. I believe the problem is that the file is not where you think it is. Did you know the real executable path is not where you think it is? It's really in some other secret hidden folder. I don't have time to get into it now, but specify the full path of the file. If it's relative then get the REAL path of your executable. Don't just give the base filename or start off the path with ../. Ask tomorrow if you still need help.

[MikeStein]

Sadly, if you look at the code above for the second (problematic) load statement, I define the absolute path for the file that's causing the issue. I'm aware that the compiled code executes in a different folder, and the first load statement corrects for that. I can help you with this issue if you need.

And like I said, the script does find and load that specific file if I don't also include the needed support paths on my mcc -a call. So I know the file exists there and it is readable.

Thanks for the reply though.