MATLAB Answers

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

1 view (last 30 days)
Tonny Madsen
Tonny Madsen on 5 Oct 2016
Commented: Bo Li on 11 Oct 2016
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!


Sign in to comment.

Accepted Answer

Bo Li
Bo Li on 5 Oct 2016
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:


Show 1 older comment
Bo Li
Bo Li on 5 Oct 2016
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
Tonny Madsen on 6 Oct 2016
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
Bo Li on 11 Oct 2016
Yes, using engOpenSingleUse on Windows for the "dummy Engine" makes sense. On Linux, engOpen is enough as Engines cannot be shared.

Sign in to comment.

More Answers (0)

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!