Deploying to evm fails with invalid memory address

[iotaledger]

Deploying to evm fails with invalid memory address

[dessaya]

@dahof1 I can't reproduce this issue. Can you provide more details? How are you deploying the contract? What are the exact steps? Is there some log you can share?

[dahof1]

Hi @dessaya,

it is strange... so here are the (complete) steps:

(Pre-step: wasp-cluster start)

wasp-cli request-funds
wasp-cli chain deploy --committee=0,1,2,3 --quorum=3 --chain=mychain --description="My chain"
wasp-cli chain deposit IOTA:1000
wasp-cli chain evm deploy --chainid 1074 --alloc "<ADDRESS>:100000000000000000000000000"
wasp-cli chain evm jsonrpc --chainid 1074

Deploy a smart contract with truffle:

truffle migrate --network wasptest

The migration fails with: (At this time i had a privateKey as deployer key)

GET http://127.0.0.1:9090/chain/mbzESjyjzkzbLEcs1JeXKYzT4gpNLA41NQqbkxSBq2Rj/contract/adc164b5/callview/getBlockByNumber: 400: View call failed: viewcontext: panic in VM: runtime error: invalid memory address or nil pointer dereference

Update 1:

Then, i switched to mnemonic as hd wallet key and afterwards the error was gone. BUT now the deployment runs like "forever". So it feels like there is no block confirmation coming. In the log i see a lot of /callview/getBlockByNumber calls, but the deployment runs...

My truffle configuration:

networks: {
wasptest01 : {
      provider: () => new HDWalletProvider(process.env.WASPTEST01_DEPLOYER_KEY, process.env.WASPTEST01_RPC),
      network_id: 1074,
      skipDryRun: true,
      confirmations: 0,
      timeoutBlocks: 0,
      from: <address>
    },
}

Update 2:

At some time (back and forth of trying :) ) i receive this error

getBlockByNumber: 400: View call failed: viewcontext: panic in VM: missing trie node 8eb2efdd2333ef16a431641c2fff2a21efbb700786cbebc77dd1b4ebb44ae586 (path )

[dessaya]

Hmm, it looks like several different bugs happening randomly 😅. I'll try to reproduce but it seems like a very specific setup.

By any chance do you have the wasp node logs? If you are using wasp-cluster they might be in /tmp/wasp-cluster or similar.

Even better, if you could repeat with logger.level = "debug" in config.json, so that we can get the stack trace when the panic happens. If you are using a disposable cluster (wasp-cluster -d) you can enable debug by editing the config template in tools/cluster/templates/waspconfig.go and then recompiling wasp-cluster.

Thanks!

[dahof1]

Hi @dessaya ,

so i ran now several tests and i hope the logs are useful.

1) First log (wasp-wrong-address.log)
wasp-wrong-address.log

The first error which led to the initial ticket was purely my fault. Truffle picked the wrong account which had no balance. In the log it is clearly saying:

2021-07-30T11:38:23Z	PANIC	Chains.p93tu9..c	vmcontext/log.go:12	assertion failed: assertion failed:  insufficient funds for gas * price + value: address 0xC0A46D280BdbF7c0B6184bd8d58F093D81C7BA5A have 0 want 134439500000000000
2021-07-30T11:38:23Z	DEBUG	Chains.p93tu9..c	vmcontext/log.go:8	panic in VM: assertion failed: assertion failed:  insufficient funds for gas * price + value: address 0xC0A46D280BdbF7c0B6184bd8d58F093D81C7BA5A have 0 want 134439500000000000
2021-07-30T11:38:23Z	DEBUG	Chains.p93tu9..c	vmcontext/log.go:8	goroutine 187 [running]:

On the client-side this error was not displayed. So maybe this would be some improvement

2) Second log (wasp-confirmation-1.log)
wasp-confirmation-1.log

In the second run i had the following truffle migration:

{
      confirmations: 1,
      timeoutBlocks: 1,
}

The depyloment runs... and runs... but the confirmation never comes. Strangly i cannot see any error in the log. But maybe (i hope) you have better eyes.

3) Third log (wasp-deployed-with-error.log)
wasp-deployed-with-error.log

In the last run i set confimations and timoutBlocks to 0. The deployment runs through but with an error in the beginning of the deployment.

In the log there is the following entry:

2021-07-30T12:02:36Z	INFO	Chains.hJ2abG..view	viewcontext/viewcontext.go:60	+++++ debug: error returned from the view call: viewcontext: panic in VM: runtime error: invalid memory address or nil pointer dereference

On the client the following is displayd:

Error: GET http://127.0.0.1:9090/chain/hJ2abGmCtcJuyjJvvdhFdL1xvuYyRdcc9eGeEsQBeqwZ/contract/adc164b5/callview/getBlockByNumber: 400: View call failed: viewcontext: panic in VM: runtime error: invalid memory address or nil pointer dereference

The SC itself got deployed 👍

I hope this is useful.

[dessaya]

Thanks for the detailed report!

Case 1) addressed in #314

Case 2) I can't find anything interesting in the log either. Maybe @lunfardo314 can help?

Case 3) Unfortunately the stack trace is not printed, so I still can't diagnose the root cause. This is also addressed in #314; I hope you can repeat after this is merged?

[dahof1]

Hi @dessaya,

Case 1)
On addresses without sufficent balance i know get also some error stacktraces 👍

Case 3)
i don't know why, but the error automagically disappeared. So corret wallet and confirmations set to 0 deploys the SC smoothly.

Case 2)
Regarding the truffle setting confirmations > 0: This is just a waiting mechanism where truffle will simply just wait N blocks after it will continue for more deployments.

So i was wondering how this can be work on the evm chain on ICSP: When does a new block appear? Only on SC state changes?
Or do we have continuously minted blocks like on a traditional blockchains?
I also had a quick look to the archictural paper but maybe i overlooked it. Maybe you have some info about that. It would also be interesting if we have something like a block time (e.g. on Binance Smart Chain it is ~ 5sec) in the future.

[dessaya]

In the current implementation, a new block will be created whenever at least 1 transaction is received. If you send 1 tx per minute, then you will most probably get 1 block per minute. If you send several txs per second, the consensus mechanism might group several of those txs in a single block. But it is currently guaranteed that if you send a tx, a block will be created as soon as the tx is picked by the evmchain contract. (This might change in the future; it might be more efficient to create 1 block per 10 minutes or so.)

[dahof1]

Ok, so than it's clear to me why my initial truffle migration with confirmation: 1 runs in an endless loop. As long as i am "alone" on the chain and no other (parallel) transactions happen, no new block gets "minted". Thats good to know if you have small test chains. Maybe it make sense to have an parallel "incrementer" SC on test setups, to simulate "traffic" on the chain.

One sidenote regarding the block time: i would vote for faster times ( < 10min). But thats just my 2 cents.

From my side we can close this ticket. Thanks for the support!