Uploading wasm file appear function non-existent error

[jeremymj]

I want to use the signature verification method in my contract,and add dependency in cargo.toml as fellow:
schnorrkel = { version = "0.9.1",features = ["preaudit_deprecated", "u64_backend"], default-features = false}
using cargo contract build command can generate wasm file normally and uploading the wasm file to node, got some error message:

2020-03-22 22:13:36.028 tokio-blocking-driver DEBUG runtime  DispatchError
2020-03-22 22:13:36.028 tokio-blocking-driver DEBUG runtime  module imports a non-existent function

using cargo-contract version is 0.5.0 ;
node of substrate version is: version 2.0.0-alpha.4-0b3020796-x86_64-linux-gnu
more about reproduce code, please go to my repository example

[Robbepop]

Can you please insert your .wasm file and tell us how you generate the .wasm file?
Did you use cargo-contract? If yes, what version? Please inspect with cargo contract --version.
Also preaudit_deprecated looks like you are using a deprecated feature.

[jeremymj]

yes,I use cargo-contract generate wasm file and cargo-contract version is 0.5.0.
Based on your suggestions, I updated the test code and removed preaudit_deprecated, but the problem persists.This is the wasm file I generated.

[Robbepop]

I don't know why it is there but I inspected your .wasm file and found the import that is causing this:

(import "env" "_ZN4core9panicking5panic17h9ff647c44ac14387E" (func (;6;) (type 1)))

To me it looks like a Rust (or C++) mangled name and probably has something to do with panicking since "panic" is mangled in its name.
So some dependency maybe is importing this?

[jeremymj]

I don't understand the meaning of this expression _ZN4core9panicking5panic17h9ff647c44ac14387E,
This dependency is estimated to be introduced in schnorrkel. You can use the github address I provided to check whether the dependency is introduced in the cargo.lock file.

[athei]

This is rust name mangeling. Something inserted a call to core::panicking::panic: https://doc.rust-lang.org/stable/core/panicking

It is an experimental API where a no_std crate can panic but then requires a another crate to actually implement the panic function. Nobody does that in your case therefore it is just an unresolved imported function. However, I cannot see schnorrkeel making use of this API. Maybe schnorrkel is a red herring.

It would be interesting which function calls panic. However, the contract is stripped of all function names. The only thing I can see is that the imported function is actually called multiple times.

[jeremymj]

@athei I used schnorrkel library from the sp-core module dependency in the substrate project, and they should also compile using no_std. If there is a problem with schnorrkel, they probably have encountered similar errors like this,

[athei]

This imported call to panic is only there when I use cargo contract for building the contract. And it is not introduced by the post processing steps but by the actual build. I tried to mimic cargo contract build as closely as possible by manual cargo commands. But I never get that panic call introduced into my wasm file.

I added this to your Cargo.toml:

[package.metadata.cargo-xbuild]
memcpy = false
sysroot_path = "target/sysroot"
panic_immediate_abort = true

And then ran

 RUSTFLAGS="-C link-arg=-z -C link-arg=stack-size=65536 -C link-arg=--import-memory" cargo +nightly xbuild --target wasm32-unknown-unknown --no-default-features --release

Which should be exactly what cargo contract is doing. However, the resulting wasm file is correct (without the panic function).

I am not sure what is happening there in cargo contract.

I then looked at the broken wasm file produced by cargo contract (I modified it to remove post processing) to look for the callers of the panic function. There are two:

(func $_ZN51_$LT$u64$u20$as$u20$core..ops..arith..AddAssign$GT$10add_assign17h1e01cef87efc54f2E (type 12) (param i32 i64)

(func $_ZN51_$LT$i64$u20$as$u20$core..ops..arith..AddAssign$GT$10add_assign17h99e945e958616f28E (type 12) (param i32 i64)

I guess these are implementations of core::ops::AddAssign. Just by which concrete type?

[athei]

After some discussion with my coworkers we found out that this problem is triggered when we stop passing rlib as additional crate-type to the compiler. cargo contract does exactly this in order to reduce the size of the resulting wasm file. When building with cargo manually the rlib is passed to the compiler. This explains the difference. What is unclear is why this is happening.

[jeremymj]

Oh, I see. Thank you for your reply to this issue. Since this problem is triggered when we stop passing rlib as additional crate-type to the compiler, is there a way to fix it?

[ascjones]

☝️ Quickly added an option to disable manifest modifications for troubleshooting. However this (with rlib as a crate-type) will likely result in a significant increase in binary size: e.g. for incrementer 18.8k vs 5.1k (optimized)

[Robbepop]

point_up Quickly added an option to disable manifest modifications for troubleshooting. However this (with rlib as a crate-type) will likely result in a significant increase in binary size: e.g. for incrementer 18.8k vs 5.1k (optimized)

Usage of this command is generally not recommended for use cases other than debugging.
My guess so far is that the library you are using is non compatible with contracts for some reason and we should find out why and not work around that problem by fiddling around with some configs here and there.
Our current findings is that the rlib target causes trouble if it is being removed. However, the reality is that this rlib option only exists because of our metadata generation process and should ideally not even be there at all. Not removing something that shouldn't exists in the first place is a clear indicator that something else is broken.

[ascjones]

Yes to be clear I was not suggesting that this was a fix for the actual problem, rather an option to allow troubleshooting using cargo contract build.

[jeremymj]

Well, I understand what you said, thanks again.