Why did MATLAB load a function from an unexpected m-file?

I'm running MATLAB 2018a. (Yeah, I know. Corporate IT.)

I have an m-file that pulls in functions from several other m-files.

Yesterday, I ran into a problem because the function that was pulled in and ran was not the function I wanted or expected.

Specifically, my main function runs a function called instrRack. This function is defined inside an m-file named instrRack.m.

I expected to get the instrRack function from the file C:\git\unified-cryo\unified\Instruments\@instrRack\instrRack.m.

Instead, the instrRack function came from the file C:\git\unified-cryo\adr\Instruments\@instrRack\instrRack.m

I discovered this by digging through the error stack returned by the use of the incorrect instrRack function.

Note that the correct file is "unified-cryo\unified" while the incorrect file is "unified-cryo\adr".

I don't believe I've seen this problem before and I've been using my main function for months, if not years.

As far as I could tell, my MATLAB path was correct. Specifically, C:\git\unified-cryo\unified was at the top of the path, with C:\git\unified-cryo\unified\Instruments a few entries below that.

Unless I missed something, C:\git\unified-cryo\adr was nowhere in the MATLAB path.

Other people use MATLAB on the same test stand. Could one of them have used a path that included the incorrect m-file, and that incorrect m-file or path somehow persisted into my MATLAB session?

I tried killing and restarting my MATLAB session several times, each time verifying that my MATLAB path was correct. However, I kept getting the function from the wrong m-file.

I wound up having to restart the PC in order to get the function from the correct m-file.

Any suggestions on why I kept getting the function from the wrong m-file?

[Stephen23]

What my AI said: This is an interesting and frustrating issue!

Most Likely Causes

1. Class Method ShadowingThe @instrRack folders indicate these are MATLAB class definitions. The @ prefix means these are class folders, and instrRack.m inside would be the constructor. MATLAB's class method resolution can be tricky:

• If an instrRack object was created from the "adr" version, calling methods on that object will use methods from that class definition, regardless of your current path
• This can persist across function calls if the object is passed around

2. Persistent import StatementsIf any code (yours or a colleague's) used import statements to bring the "adr" package into scope, these imports can persist in the MATLAB workspace even after clear all. Only clear classes or restarting MATLAB clears them.

3. Hidden Path EntriesCheck for:

• javaaddpath or javaclasspath.txt entries
• Path additions in startup.m files (check both your user folder and the MATLAB installation directory)
• pathdef.m modifications

4. MEX File or P-Code CachingIf there are compiled MEX files or P-coded versions, MATLAB caches these aggressively. They won't show up in typical path searches but will execute preferentially.

Diagnostic Commands to Run

% Find ALL instrRack files
which instrRack -all
% Check for class definitions specifically
which @instrRack/instrRack -all
% See what's actually being called
dbstop if error  % Then trigger the error and check the stack
% Check for hidden path issues
restoredefaultpath
savepath  % If this fixes it, something was corrupting pathdef.m

Why Restarting Fixed It

The fact that restarting MATLAB multiple times didn't fix it, but restarting the PC did, suggests:

• A locked file handle or shared memory issue
• A system-level environment variable affecting MATLAB's startup
• Antivirus or file monitoring software holding locks

Recommendations

1. Use clear classes instead of just restarting MATLAB when you encounter this
2. Add to your main script: rehash toolboxcache at the beginning
3. Verify no one added the "adr" path: Check your team's shared startup.m or pathdef.m files
4. Use absolute path diagnostics: Add this to your main function:

instrRackPath = which('instrRack');
assert(contains(instrRackPath, 'unified\Instruments'), 'Wrong instrRack loaded from: %s', instrRackPath);

Consider using packages (if upgrading is possible) to avoid name collisions entirely

The corporate IT situation with older MATLAB is understood, but this shadowing behavior is exactly why MATLAB improved its package system in later versions!

[Bob]

Thanks! Given the extremely intermittent (i.e. never before seen) nature of this problem, any debugging will have to wait until this is seen again. However, you've given me some things to check as well as some things to try.

[Rik]

which('instrRack','-all')

can also help a lot in figuring out which functions shadow which call. The full list can provide a lot of information you weren't expecting (especially when things go wrong).