Here is a way to reproduce the issue:

https://github.com/gfusee/child-deployed-contract-payable-call-error-demo

The CodeMetadata "Payable By SC" seems to be ignored

It happens with the VM 1.5.25. I never encountered this issue with the VM 1.5.19

see this multiversx/mx-chain-go#5344

It would be nice if we could put erd addresses in Mandos tests and get them correctly encoding.

I guess it consists in modifying the InterpretString method in wasm-vm/mandos-go/expression/interpreter/interpreter.go. If I submit a PR for this, would it have chances to be accepted?

Has anybody tested whether Hyperledger's Solang https://github.com/hyperledger-labs/solang produces wasm that Arwen can run? Elrond looks fantastic, but incompatibility with Solidity is a bummer.

You can find the reproduction here: https://github.com/lcswillems/mx-vm-bug

The test passes with vm 1.4.60 but not with 1.4.77.

Problem

It is frequent that a caller A calls a SC B with a token, the SC B transforms the received token and then send the transformed token back to the caller A.

In the case where the caller A is a SC and the SC B sends back the token with additional data (e.g. self.send().direct(&receiver, &id, &nonce, &amount, b"Some data")), the transaction will fail with the error Not enough gas. You can see a reproduction of the issue here.

We believe that from a developer point of view (if we forget the blockchain implementation details that leads to this error), the transaction should not fail. The additional data should be written in the blockchain and the token should be transferred, but no smart contract call should be done.

Currently, the transaction fails because self.send().direct(..., b"Some data") sends a token to the receiver while setting the gasLimit to 0 and the function name to "Some data". In other words, the blockchain will not only send the token to the receiver but all call the method "Some data" of the receiver. However, because the gasLimit is set to 0, the transaction will necesseraly fail.

Solution

We believe the blockchain should try to call the receiver method only if the receiver is a smart contract, a function name has been specified, and gasLimit > 0.

We made a pull request to fix this: #569

It is theoretically possible.

Are there any examples besides rust or C/C++ ?

There is probably something wrong in arwen.go:

`arwen-wasm-vm/cmd/test$ go build

# github.com/ElrondNetwork/arwen-wasm-vm/arwen/context
../../arwen/context/arwen.go:189:101: cannot use "uniform_one" (type string) as type *[410]uint32 in argument to wasmer.NewMeteredInstanceWithImports
`

Or I don't know how to build arwen-wasm-vm. Please add howto build it in README.md.Thanks Florian

The opcode managedOwnerAddress crashes with the error "account not found [...]" during the contract's deployment. I only tested this behavior on scenarios

Scenario of a real flow made by XOXNO:

• Someone pays to create his first event, we are requesting from the user all info about the event + collection details (token name, token ticker).

• We have in our manager SC an endpoint called register that is payable.

• Each register transaction is deploying a child SC for the specific user, in the same transaction we would want to trigger also inside the child SC an ESDT token issuing request.

Currently the above flow fails at the issuing of the transaction towards the newly created child SC address (as far as I remember with the error: account not found).

I suspect that the VM is not allowing transaction execution to new SCs until the SC deploy TX is not final.

A snippet from our flows:

    #[payable("EGLD")]
    #[endpoint(listing)]
    fn listing(
        &self,
        tag: &ManagedBuffer,
        cid: ManagedBuffer,
        tags: ManagedBuffer,
        base_nft_name: ManagedBuffer,
        royalties: BigUint,
        token_name: ManagedBuffer,
        token_ticker: ManagedBuffer,
        collection_size: usize,
        global_max_per_wallet: u32,
        collectiontag: ManagedBuffer,
        nft_ending: ManagedBuffer,
        name_shuffle: bool,
        has_attributes: bool,
        has_kyc: bool,
        refund_policy: bool,
        public_burn: bool,
        bot_protection: bool,
        has_reveal: bool,
    ) {
        let payment_amount = self.call_value().egld_value();
        let fees = self.register_fees().get();
        require!(
            payment_amount.clone_value() == (&fees + NFT_ISSUE_COST),
            "The fees paid is not matching the required amount + issuing the collection ticker!"
        );

        let new_contract = self.common_register(
            tag,
            OptionalValue::None,
            OptionalValue::Some(self.blockchain().get_caller()),
        );

        self.tx()
            .to(self.accumulator_sc().get())
            .typed(accumulator::AccumulatorProxy)
            .deposit()
            .egld(fees)
            .sync_call();

        self.tx()
            .to(new_contract)
            .typed(launchpad_proxy::MinterProxy)
            .listing(
                cid,
                tags,
                base_nft_name,
                royalties,
                token_name,
                token_ticker,
                collection_size,
                global_max_per_wallet,
                collectiontag,
                nft_ending,
                name_shuffle,
                has_attributes,
                has_kyc,
                refund_policy,
                public_burn,
                bot_protection,
                has_reveal,
            )
            .egld(NFT_ISSUE_COST)
            .sync_call()
    }

Scenario: mandos/buy.scen.json ... FAIL: unexpected log. Tx purchase-nft. Log index: 0. Log:{
"address": "address:buyer",
"endpoint": "str:internalVMErrors",
"topics": [
"00000000000000006e66742d737761705f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f",
"7075726368617365"
],
"data": "0a092f55736572732f6d65726c65612f656c726f6e6473646b2f766d746f6f6c732f76312e342e34322f7761736d2d766d2d312e342e34322f617277656e2f636f6e74657874732f72756e74696d652e676f3a31303233205b6572726f72207369676e616c6c656420627920736d617274636f6e74726163745d205b70757263686173655d0a092f55736572732f6d65726c65612f656c726f6e6473646b2f766d746f6f6c732f76312e342e34322f7761736d2d766d2d312e342e34322f617277656e2f636f6e74657874732f72756e74696d652e676f3a31303233205b6572726f72207369676e616c6c656420627920736d617274636f6e74726163745d0a092f55736572732f6d65726c65612f656c726f6e6473646b2f766d746f6f6c732f76312e342e34322f7761736d2d766d2d312e342e34322f617277656e2f636f6e74657874732f72756e74696d652e676f3a31303230205b4e6f7420656e6f75676820737570706c792e5d"
}

Decoded:
/Users/me/elrondsdk/vmtools/v1.4.42/wasm-vm-1.4.42/arwen/contexts/runtime.go:1023 [error signalled by smartcontract] [purchase]
/Users/me/elrondsdk/vmtools/v1.4.42/wasm-vm-1.4.42/arwen/contexts/runtime.go:1023 [error signalled by smartcontract]
/Users/me/elrondsdk/vmtools/v1.4.42/wasm-vm-1.4.42/arwen/contexts/runtime.go:1020 [Not enough supply.]

{
        "step": "scCall",
        "txId": "purchase-nft",
        "tx": {
            "from": "address:buyer",
            "to": "sc:nft-swap",
            "function": "purchase",
			"value": "300",
            "arguments": [
                "1",
				"300"
            ],
            "gasLimit": "20,000,000",
            "gasPrice": "0"
        },
        "expect": {
            "out": [],
            "status": "4",
            "message": "str:Not enough supply.",
            "gas": "*",
            "refund": "*",
			"logs": []
        }
    },

When the parent contract upgrades its child contract, the transaction doesn't fail but the child contract doesn't have its code changed

Here is a repo that reproduces the issue: https://github.com/gfusee/upgrade-contract-error-demo

This bug happens in both 1.5.19 and the 1.5.25 versions of the VM