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

Incorrect STACKTOP in asm side modules #8433

Closed
rianhunter opened this issue Apr 11, 2019 · 2 comments · Fixed by #8434
Closed

Incorrect STACKTOP in asm side modules #8433

rianhunter opened this issue Apr 11, 2019 · 2 comments · Fixed by #8434

Comments

@rianhunter
Copy link
Contributor

When emitting an ASM side module, emscripten sets STACKTOP in the shell:

var STACKTOP = getMemory(TOTAL_STACK);

But this STACKTOP variable is overridden when emitting the asm variables in emscripten.py:

stack += apply_memory(' var STACKTOP = {{{ STACK_BASE }}};\n')

This causes the side module to corrupt memory because its STACKTOP is not the dynamically allocated STACKTOP obtained from the side module shell, and is a lower STACKTOP taken from considering only the globals in the side module.

My fix would be to change the condition in emscripten.py:

if not (shared.Settings.WASM and shared.Settings.SIDE_MODULE):

But I'm not sure if that is the correct change.

@kripken
Copy link
Member

kripken commented Apr 11, 2019

I think for side modules in general, not just asm.js ones, we can't know their stack location at compile time. So yes, I think the fix is to change that condition to not happen for any side module.

@rianhunter
Copy link
Contributor Author

I came up with a set of changes that seem to be consistent with the surrounding code. The distinction wasn't side modules but "relocatable" modules. Unfortunately two tests are failing, so I'm still investigating that but if you can, let me know if I'm on the right track.

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