Assertion failed: old table entries must remain the same

[donalffons]

Here is another simplified test case / minimal version to reproduce this error.

main.js:1529 Uncaught (in promise) RuntimeError: abort(Assertion failed: old table entries must remain the same) at Error
    at jsStackTrace (https://embind-dynamic-libs-02-git-master.donalffons.vercel.app/emscripten/build/main.js:1782:19)
    at stackTrace (https://embind-dynamic-libs-02-git-master.donalffons.vercel.app/emscripten/build/main.js:2297:16)
    at abort (https://embind-dynamic-libs-02-git-master.donalffons.vercel.app/emscripten/build/main.js:1523:44)
    at assert (https://embind-dynamic-libs-02-git-master.donalffons.vercel.app/emscripten/build/main.js:701:5)
    at postInstantiation (https://embind-dynamic-libs-02-git-master.donalffons.vercel.app/emscripten/build/main.js:2059:13)
    at https://embind-dynamic-libs-02-git-master.donalffons.vercel.app/emscripten/build/main.js:2084:20
    at async Promise.all (index 1)
    at abort (https://embind-dynamic-libs-02-git-master.donalffons.vercel.app/emscripten/build/main.js:1529:11)
    at assert (https://embind-dynamic-libs-02-git-master.donalffons.vercel.app/emscripten/build/main.js:701:5)
    at postInstantiation (https://embind-dynamic-libs-02-git-master.donalffons.vercel.app/emscripten/build/main.js:2059:13)
    at https://embind-dynamic-libs-02-git-master.donalffons.vercel.app/emscripten/build/main.js:2084:20
    at async Promise.all (index 1)

Repo: https://github.com/donalffons/embind-dynamicLibs-02
Deployment: https://embind-dynamic-libs-02-git-master.donalffons.vercel.app/javascript

• The error occurs during WASM instantiation, randomly, i.e. not every time. Therefore, I perform the WASM instantiation in an infinite loop until the error occurs. When I run this example from the web server deployment, I get this error quite frequently. If I run it from localhost, it seems to occur less frequently.
• There is 1 MAIN_MODULE, which loads 2 SIDE_MODULES (A and B). SIDE_MODULE A contains problematic code, while SIDE_MODULE B is empty. Only loading SIDE_MODULE A without B does not yield the error.
• There is virtually no Embind code, no bindings are defined.
• The problematic code in SIDE_MODULE A is based on code from the OpenCascade project and looks like this.

// library1.cpp
class Standard_MMgrRoot {};

class Standard_MMgrFactory
{
public:
  static Standard_MMgrRoot* GetMMgr();
  ~Standard_MMgrFactory(){} // Error doesn't occur without this line

private:
  Standard_MMgrRoot* myFMMgr;
};

Standard_MMgrRoot* Standard_MMgrFactory::GetMMgr()
{
  static Standard_MMgrFactory aFactory; // Error doesn't occurr without this line
  return aFactory.myFMMgr;
}

• The error could be reproduced even with a bit less code, but I left a few extra lines in here for context - maybe a more experienced C++ developer can recognize this pattern.

@sbc100, @kripken, if there is anything I can do to support in fixing this (without needing extreme in-depth knowledge of Emscripten internals), hit me 🙂.

[donalffons]

...even if I take out this specific problematic code from my actual project, I still get the same error message. I guess this specific code is not the only thing that can cause this error message.
If its of any help, I could try create another test case which reproduces this issue with different code?! Maybe this could help in narrowing the root cause down?

[donalffons]

Yeah, well, it turns out there is an easier way to reproduce the same error:

// library1.cpp
#include <iostream>

class aClass {
public:
  aClass() {
    std::cout << "Hello, World!" << std::endl;
  }
};

aClass instanceOfAClass;

(if I leave out the iostream / cout stuff, the error doesn't occur. Maybe the compiler optmizes things out in that case?!)

I updated the repo and deployment. I hope there is no fundamental flaw in how I want to use Embind + dynamic libraries (if so, I would appreciate it, if you would let me know 🙂).

[donalffons]

This example is probably as minimal as it gets while producing the same error.

// library1.cpp
class aClass {
public:
  ~aClass(){}
};

aClass instanceOfAClass;

I updated the repo and the deployment from the original post again. Weird thing is that if I remove the destructor (and add a constructor, for example), there is no error.

[kripken]

Thanks for the testcase! Looks like the assertion here is racy, and just needs to be removed. See #13060

[donalffons]

Thank you! This probably also fixes #11458.
I will probably have more of those cases. Will do more testing as soon as this pr is merged and in tip-of-tree.

[kripken]

Good point, this does look like it fixes that other issue too, thanks!