Error when calling a method on a deployed contract using burrow deploy

[devos50]

Describe the Bug
I've been playing a bit around with Burrow and

To Reproduce
I deployed the basic contract as included in the tests. My deploy.yaml file looks as follows:

jobs:

- name: deployStorageK
  deploy:
      contract: simple.sol

This succeeds with the following output:

log_channel=Info message="Using chain" Chain=127.0.0.1:10997 Signer=
log_channel=Info message="Loading Playbook File."
log_channel=Info message="Loading playbook file" path=/home/pouwelse/energy_trading_smart_contract filename=/home/pouwelse/energy_trading_smart_contract/deploy.yaml
log_channel=Info message="*****Executing Job*****" JobName=defaultAddr Type=Account
log_channel=Info message="Setting Account" account=0FCBFAD20386C1AAF0EC4D6C6776D91AA1BF8E95
log_channel=Info message="*****Executing Job*****" JobName=deployStorageK Type=Deploy
log_channel=Info message="Contract path" path=simple.sol
log_channel=Info message="Saving Binary" contract=SimpleStorage
log_channel=Info message="Using mempool signing since no keyClient set, pass --keys to sign locally or elsewhere"
log_channel=Info message="Using mempool signing"
log_channel=Info message="Tx Return" addr=987AED324ABE094F1B351F52617D9A7E2465DAF6 TransactionHash=0ab73f5c35319f6e448efde70ee8ea46ebd8d75ca59a8d530d91aeb9e812e089
log_channel=Info message="Writing to current directory" output=/home/pouwelse/energy_trading_smart_contract/deploy.output.json
log_channel=Info message="JOBS THAT SUCCEEDED" count=1
log_channel=Info message="Playbook result" jobNo=0 file=deploy.yaml time=149.707315ms

Next, I change the deploy.yaml file and try to call a method in the contract:

- name: setStorageBool
  call:
      destination: 987AED324ABE094F1B351F52617D9A7E2465DAF6
      function: setBool
      data:
        - true

This fails with the following error:

log_channel=Info message="Using chain" Chain=127.0.0.1:10997 Signer=
log_channel=Info message="Loading Playbook File."
log_channel=Info message="Loading playbook file" path=/home/pouwelse/energy_trading_smart_contract filename=/home/pouwelse/energy_trading_smart_contract/deploy.yaml
log_channel=Info message="*****Executing Job*****" JobName=defaultAddr Type=Account
log_channel=Info message="Setting Account" account=0FCBFAD20386C1AAF0EC4D6C6776D91AA1BF8E95
log_channel=Info message="*****Executing Job*****" JobName=setStorageBool Type=Call
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xeac66f]

goroutine 42 [running]:
github.com/hyperledger/burrow/deploy/def.(*Client).GetMetadataForAccount(0xc000b44630, 0xaac18603d2facb0f, 0x1ad976676c4decf0, 0xc0958ebfa1, 0x0, 0x0, 0x0, 0x0)
	/home/pouwelse/gocode/src/github.com/hyperledger/burrow/deploy/def/client.go:147 +0x11f
github.com/hyperledger/burrow/deploy/jobs.FormulateCallJob(0xc000b400c0, 0xc000ce6690, 0xc000c38b40, 0xc000b44630, 0xc000cf1cb0, 0x4, 0x4, 0x0)
	/home/pouwelse/gocode/src/github.com/hyperledger/burrow/deploy/jobs/jobs_contracts.go:452 +0xbd3
github.com/hyperledger/burrow/deploy/jobs.doJobs(0xc000c38b40, 0xc000ce6690, 0xc000b44630, 0xc000cf1cb0, 0x0, 0x1)
	/home/pouwelse/gocode/src/github.com/hyperledger/burrow/deploy/jobs/job_manager.go:241 +0x2143
github.com/hyperledger/burrow/deploy/jobs.ExecutePlaybook(0xc000ce6690, 0xc000c38b40, 0xc000b44630, 0xc000cf1cb0, 0x0, 0x0)
	/home/pouwelse/gocode/src/github.com/hyperledger/burrow/deploy/jobs/job_manager.go:332 +0x1fb
github.com/hyperledger/burrow/deploy.worker.func1(0x7fffffffdee6, 0xb, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
	/home/pouwelse/gocode/src/github.com/hyperledger/burrow/deploy/run_deploy.go:66 +0x224
github.com/hyperledger/burrow/deploy.worker(0xc000c38a80, 0xc000c38ae0, 0xc000ce6690, 0xc000cf1cb0)
	/home/pouwelse/gocode/src/github.com/hyperledger/burrow/deploy/run_deploy.go:71 +0x262
created by github.com/hyperledger/burrow/deploy.RunPlaybooks
	/home/pouwelse/gocode/src/github.com/hyperledger/burrow/deploy/run_deploy.go:100 +0x1f2
[pouwelse@fs3 energy_trading_smart_contract]$ burrow deploy --address $ADDRESS -v deploy.yaml
log_channel=Info message="Using chain" Chain=127.0.0.1:10997 Signer=
log_channel=Info message="Loading Playbook File."
log_channel=Info message="Loading playbook file" path=/home/pouwelse/energy_trading_smart_contract filename=/home/pouwelse/energy_trading_smart_contract/deploy.yaml
log_channel=Info message="*****Executing Job*****" JobName=defaultAddr Type=Account
log_channel=Info message="Setting Account" account=0FCBFAD20386C1AAF0EC4D6C6776D91AA1BF8E95
log_channel=Info message="*****Executing Job*****" JobName=setStorageBool Type=Call
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xeac66f]

However, when 'combining' the deploy and call job in the same contract, it succeeds.

Expected Behavior
The transaction succeeds.

Technical Details

• Burrow Version (docker image tag or branch if built from source): 0.29.8+commit.6205f48346a370d553388de37b4d6dc4a06dfb7e+2020-02-11T13:09:22Z
• Operating System (osx/windows/linux): CentOS 6

[devos50]

Any progress on this issue?

[devos50]

It actually seems to work when passing the --local-abi flag to the burrow deploy command (found about this when going through the source code). Is there a bug when fetching the contract ABI from Burrow?

[gregdhill]

Sorry for the late reply @devos50! Burrow needs to know where your ABIs are stored so it can properly encode your function call. You can do what you've done above, or you can specify bin on the call job.

[devos50]

No problem! (decided to look at it myself since we're using Burrow to evaluate a smart contract for a scientific paper with the submission deadline soon).

I tried several times to add a bin parameter to the contract, but that did not seem to work for some reason. Furthermore, Burrow does not give me an error about an invalid or missing ABI but instead, the error is in the GetMetadataForAccount method. I found that the specific erroneous line is only triggered when the localABI argument is not set.

[gregdhill]

Hmm okay, this is odd behavior indeed! Let me investigate this further.