What is the "primary message table for module 77"?

We use the engine interface to call functions in Matlab from Python. But every now and then we get the following message during engOpen, after which the application exists unconditionally:

Internal Error: A primary message table for module 77 was already registered with a differing collection of error messages.
Process exited with code 1

What exactly is going on here? Right my application exits consistently for R2016a!

A little background:

• We open the engine multiple times from the application. We sometimes see some transient errors from Matlab, in which case, we close the engine and re-open it again. This works fine in our unit tests (where Matlab is opened via the engine API 15 times) and most of the time in the application.
• We have seen this problem both in Matlab R2011b and R2016a (we have not used any on the intervenient releases) Right now we see the issue consistently on R2016a!

Answer 1

[Bo Li]

You may try to create a dummy Engine object using engOpen and keep it alive until the end of the application. Meanwhile, you can use engOpen to create Engine repeatedly. The dummy Engine can avoid the issue of unloading/loading of related libraries.

The other solution is to consider MATLAB Engine API for Python:

http://www.mathworks.com/help/matlab/matlab-engine-for-python.html

[Tonny Madsen]

Thanks for the suggestions.

I'll look into the first idea first - keeping the engine open. But one of the reasons we re-open the engine is because we have Matlab code with transient errors (often hardware related). In this case, we will really want to close the "old" Matlab instance and start a new "clean" instance. Otherwise the "old" context in terms of global variables, Java global variables and connections to hardware (various soundcards and communication media) can well mean the same error will occur again or something new.. A "global outer" open Matlab engine would mean we keep the global context across the "inner" Matlab engines - exactly what we want to avoid.

The official library for python have a number of issues: as I remember, it does not work with our Python version (3.5) and it does not work with Matlab R2011b.

[Bo Li]

I don't quite understand the "old" context issue. All I suggested was to create a "dummy Engine" and keep it open so the libraries used by all Engine clients are not loaded and unloaded repeatedly. "dummy Engine" is meant to be created but not used, so there should be no such "context" issue. Any other Engine that you create will be a brand new MATLAB process, which should not be affected by this "dummy Engine".

Yes, the "dummy Engine" does waste some memory.

[Tonny Madsen]

The thing is that all Matlab engines you open with engOpen (and not engOpenSingleUse) share a global context - so global variables in one instance is identical to the global variables in another instance. Likewise for Java stuff and any loaded shared libraries (dll/so) as well as any open files.

And we when have a failing test and wish to repeat it, then we need to start a completely new and virgin Matlab instance, which should not have any of the java jars, shared libraries or files open...

We also have had a few cases where the test code have had infinite loops (by accident), so the call of engEvalString never returned. In this case, I have been able to open a new engine with engOpen, and then call engEvalString('exit;') in this new engine. And thus exited the original engine and have the original engEvalString return. Not very pretty, but it works and it saves me from repeating the complete set of tests (which takes 5-6 hours).

I have solved my problem with your solution though with a twist: the first engine is opened with engOpenSingleUse and the later are opened with engOpen. That seems to work.

[Bo Li]

Yes, using engOpenSingleUse on Windows for the "dummy Engine" makes sense. On Linux, engOpen is enough as Engines cannot be shared.