Module find_function is producing an opaque Wasm3Error

[ericflo]

I've been having some trouble using the find_function function to find an export from a loaded module. Originally thought it was because of the new closure stuff, but in working on reducing the code down to a reproducible test, even removing all the linked closures and still calling find_function, it's still resulting in an error. The problem is, the error is somewhat opaque: Wasm3(Wasm3Error(0x7ff7549b9468)). It seems that either something is wrong with the wasm that I'm trying to load, and it would be useful to have the facility to get at the underlying error details or message, or something is happening in the library's find_function code, where fixing that issue will make the opaque error stuff moot.

Code to reproduce is here: https://gist.github.com/ericflo/92bc57abb301a2b66474913ee0c1d919 and the system.wasm is hosted here: https://www.siacdn.com/_BGbMn73JOQub3XQgqyRmoDJgBlZLfe7EHLTjaGblCX1mw - It's a custom quickjs build with a few extra import/exports that I'm trying to hook with these rust bindings.

[ericflo]

BTW I just want to say thank you for these bindings in general - it's a sane API and despite the rough edges just from being so new, it's shaping up to be a great library.

[Veykril]

You can print the error via the Display trait, which will give you the actual description as its a an error originating from wasm3 itself. In your case its missing imported function. The problem here is that all direct wasm3 errors are pointers to static cstrings which is why they are so opaque and unfortunately not nice to use as you cant match against static pointers(For this specific error I could potentially filter it out tho to lift it into the rust error enum on its own by checking whether it is this specific error).

So it seems like you are missing to link some import for the module.

[Veykril]

Also the reason as to why find returns this error is that find tries to compile the function you look up if it hasnt been compiled yet.

[ericflo]

Aha, I see the error Display trait impl now, that's helpful. Makes sense to try to compile if it's not found too. I think it's probably not worth doing something for this specific error, maybe more of just a documentation note or for examples/. I'll close this issue, thanks!

Unfortunately, when I do hook up the imports, it's getting to that next line where it does func.call(), and then program is exiting with no message (not result-Err-ing as I'd expect, or even panicing) - so I'm a bit worried whatever is happening next is in wasm3-sys land. It's a bit harder to build a minimal repro case because I'll have to drag in a bunch of code for all those functions. I'll do more investigation, but if you have any pointers on where to look, any are appreciated!

[Veykril]

Ye the docs, as usual, can be improved quite a bit since currently they are mostly just one-liners.

The crash might have actually been on my part doing something wrong, I just pushed a small change(55eb819de9c7070b77204f510368593d16746f45) that might help you out. I only realized now that what I'm doing when checking the call result might be wrong. I hope this is the cause for your other problem though it might not be related.

[ericflo]

Just gave it a shot, and no luck - but glad you caught that anyway

[ericflo]

I've been working on annotating the library code with some debug statements (well, using info! because of dumb reasons) to dig into the issue, and it's getting right up to the point where the actual function is called, it's not the preamble or casting or unsafe stuff, it crashes right at the ffi function call. Here's the line https://github.com/ericflo/wasm3-rs/blob/debugging/src/function.rs#L184 Not too sure where to look from here, but I'll keep digging. @Veykril - Should I open a new ticket to track this function call crasher? I hate to keep opening tickets but this does appear to be something happening within the boundary of the library

[Veykril]

Yes feel free to make it a new issue. The problem with the crash occurring here is now that it either means that wasm3 cant handle something(which is unlikely cause to my knowledge they test quite well) or me doing something wrong before the call happens.

[Veykril]

Okay, I found one other small thing that might have caused you trouble(though its probably also not the case). The initial call values were 666 and NaN which might be problematic for optimized wasm, so I changed them to 0 and 0.0 respectively in the last commit. If you got the time you could check if that fixes it.

Also thanks a lot for trying to pin-point the problem so far(and considering using the lib in general)😄

[ericflo]

Thanks for looking into it further - it's still crashing right at that point of function call. I'm trying to reduce down my test case to minimal so that it's easier to trace through - need to update the wasm first though.