Skip to content
New issue

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

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

Already on GitHub? # to your account

C-Api uses wrong exports tables #5304

Open
ubamrein opened this issue Dec 13, 2024 · 1 comment
Open

C-Api uses wrong exports tables #5304

ubamrein opened this issue Dec 13, 2024 · 1 comment
Assignees

Comments

@ubamrein
Copy link
Contributor

Describe the bug

During our exploration of trying to get wasmer running in an iOS app we encountered multiple different issues (#5302 and #5303). After we fixed the build issues, we encountered weird runtime errors.

Our WASM code failed at random locations, with errors indicating wrong/invalid signatures. Diving into the c-api specification, we encountered a bug in wasmer, in how the export table of the instance (leading to the function pointers of actual wasm functions) is matched against the export table of the module (giving signature and name).

Currently, wasmer expects the module export table to have the same order as the appearances in the WASM file itself. This is though not what the specification says (or rather it is not defined), which leads to the problem of UB when running a WASM file.

The c-api clearly says that the order of wasm_instance_exports and wasm_module_exports (https://docs.wasmtime.dev/c-api/wasm_8h.html#a390541a754c77832161daefd81fef622) are always in the same order (here we think there was also a bug in wasmi, bumping it to the newest version (0.40) fixed the order problem on their side). But the c-api does not say anything about how the order of either of the two *_exports function are related to the order in the WASM-file itself.

In order to get it running for our use case (as we were a bit in a hurry), we just fixed the export naming part, but we are not sure, if there are other places that need adjustment. We are glad to further assist, and also make a PR as soon as it is clear, where and what has to be adjusted :)

@syrusakbary
Copy link
Member

Great catch! @xdoardo will follow up on this one

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants