Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting "Assertion failed: old table entries must remain the same when linking with multiple dynamic libraries" #11458

Closed
gorinje opened this issue Jun 21, 2020 · 4 comments · Fixed by #13060

Comments

@gorinje
Copy link

gorinje commented Jun 21, 2020

Hi,

Setting dynamicLibraries to more than one .wasm files always provide this error :

Assertion failed: old table entries must remain the same

whatever .wasm files are used.

This is cause by this assert in the generated .js file :

for (var i = 0; i < tableBase; i++) {
        assert(table.get(i) === oldTable[i], 'old table entries must remain the same');
}

The last index of oldTable[i] is always null although table.get(i) has a value.

@gorinje
Copy link
Author

gorinje commented Jun 21, 2020

Commenting this line assert make the project work though.

@sbc100
Copy link
Collaborator

sbc100 commented Jun 22, 2020

How are you building your side modules? Can you provide a full example perhaps?

Are you using the RUNTIME_LINKED_LIBS option? Or setting Module.dynamicLibraries programatically?

@gorinje
Copy link
Author

gorinje commented Jun 24, 2020

You are perfectly right, my issue lacks of context. Sorry for that.

My side modules are compiled with the following flags :
-s SIDE_MODULE=1 -s EXPORTED_FUNCTIONS='["_xxxxx"]'

And the main module with :
-s "EXTRA_EXPORTED_RUNTIME_METHODS=['ccall']" -s TOTAL_MEMORY=20MB -s USE_SDL=2 -s USE_ZLIB=1 -s FETCH=1 --emrun -fPIC -s MAIN_MODULE=1

All compilations have been made with -fPIC. All dynamic libraries are linked with Module.dynamicLibraries. I have got 4 side modules. Adding one of them work, but adding any of two of them or more causes this line to raise an assert. Commenting it makes the program working though.

@sbc100
Copy link
Collaborator

sbc100 commented Jun 24, 2020

Interesting .. perhaps we don't have enough testing with multiple side modules.

kripken added a commit that referenced this issue Dec 17, 2020
If 2 side modules are loaded, A and B, and loadModule is called on A, then B,
then it is possible that if instantiation is done async here then the
postInstantiation() callbacks may happen in the reverse order, racily. If that
happens, the extra assertions on the table not changing can fire incorrectly -
the other parts of the table will appear to have changed meanwhile, but for
valid reasons.

Fixes #13054
Fixes #11458
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants