eosc
eosc copied to clipboard
Unpack not in parity with cleos (fails on delayed trx)
The following json content fails on eosc, but works on cleos: (from block ID a8484bd676f62e09e38fa27e19ea962430a3141759b6a1d419dca38630d62a10)
"signatures": [
"SIG_K1_Kju5zGHxKuzVVFUbmBgcMd8AcabVpq54nRNPFG9eiAkTkDpcv4R7HQmQe1qnuoNJxFYZbiQ9Zh5nTpqLyC6ESFcUxvb7HG"
],
"compression": "none",
"packed_context_free_data": "",
"packed_trx": "4e88995b0061b52eeccd00001e000100a6823403ea3055000000572d3ccdcd0140e951d35d93919a00000000a8ed32322740e951d35d93919a202952d35d93919a204e00000000000004454f53000000000668656c6c6f3200"
}
eosc tx unpack mytx.json --skip-sign panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x8a3334]
github.com/eoscanada/eosc/eosc/cmd.glob..func55(0xe06c80, 0xc42012ee60, 0x1, 0x2)
/home/stepd/go/src/github.com/eoscanada/eosc/eosc/cmd/txUnpack.go:30 +0x144
github.com/eoscanada/eosc/vendor/github.com/spf13/cobra.(*Command).execute(0xe06c80, 0xc42012ee00, 0x2, 0x2, 0xe06c80, 0xc42012ee00)
/home/stepd/go/src/github.com/eoscanada/eosc/vendor/github.com/spf13/cobra/command.go:766 +0x2c1
github.com/eoscanada/eosc/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xe02080, 0xe080d0, 0xc420185f40, 0x894fae)
/home/stepd/go/src/github.com/eoscanada/eosc/vendor/github.com/spf13/cobra/command.go:852 +0x30a
github.com/eoscanada/eosc/vendor/github.com/spf13/cobra.(*Command).Execute(0xe02080, 0xc42009c058, 0x0)
/home/stepd/go/src/github.com/eoscanada/eosc/vendor/github.com/spf13/cobra/command.go:800 +0x2b
github.com/eoscanada/eosc/eosc/cmd.Execute()
/home/stepd/go/src/github.com/eoscanada/eosc/eosc/cmd/root.go:34 +0x2d
main.main()
/home/stepd/go/src/github.com/eoscanada/eosc/eosc/main.go:20 +0x20
It also fails with the data from cleos PR ref: https://github.com/EOSIO/eos/pull/5225 on two aspects:
- refuses the "SignedTransaction.packed_context_free_data " if it is an empty string instead of empty array
- if we get passed this, we get the same nil pointer dereference...
the tx unpack
commands handles non-packed transactions.. perhaps it would be better worded differently.. tx unpack
handles those transactions written with --write-transaction
.
The one you are showing is a PackedTransaction
.. ok.. let's think about that.
j'ai eu le meme problem.... serait utile de le supporter pour debugger des trx packed_trx