Function signature is not correctly encoded when multidimensional arrays are part of the signature

[jondoe1337]

Found another bug while decoding a transaction...
Given a transaction:
https://etherscan.io/tx/0xfd4df264f31ea4486cc10a750b892a1eb290e2fbe07c3ea882ded98a13644b8c
And using the ABI:
https://etherscan.io/address/0x12459c951127e0c374ff9105dda097662a027093#code

Expected:
Invocation is found in org.ethereum.core.CallTransaction.Contract.parseInvocation(byte[])

Result:
Invocation is not found because the String containing the signature is build the wrong way.
Signature according to ABI: batchFillOrKillOrders(address[5][],uint256[6][],uint256[],uint8[],bytes32[],bytes32[])
However the signature string is build like this: batchFillOrKillOrders(address[][5],uint256[][6],uint256[],uint8[],bytes32[],bytes32[]).

I think this is someone wrong done in the org.ethereum.solidity.SolidityType.StaticArrayType.getCanonicalName() where the canonical type of the actual element type is prepended before the actual size.

I could try to provide a fix if desired.

[mkalinin]

The fix would be much appreciated 👍 good catch, btw

[jondoe1337]

I created the PR for the initial bug: #1221

However, I tried the ethereumj lib now with my initial unittest which then will try to decode the method.
Now I the signature is correctly found, but then I will get an Exception in the decoding of the input params:

java.lang.ArrayIndexOutOfBoundsException
	at java.lang.System.arraycopy(Native Method)
	at java.util.Arrays.copyOfRange(Arrays.java:3521)
	at org.ethereum.solidity.SolidityType$IntType.decodeInt(SolidityType.java:419)
	at org.ethereum.solidity.SolidityType$IntType.decode(SolidityType.java:429)
	at org.ethereum.solidity.SolidityType$AddressType.decode(SolidityType.java:372)
	at org.ethereum.solidity.SolidityType$DynamicArrayType.decode(SolidityType.java:246)
	at org.ethereum.solidity.SolidityType$StaticArrayType.decode(SolidityType.java:182)
	at org.ethereum.solidity.SolidityType$StaticArrayType.decode(SolidityType.java:146)
	at org.ethereum.core.CallTransaction$Function.decode(CallTransaction.java:158)
	at org.ethereum.core.CallTransaction$Function.decode(CallTransaction.java:166)
	at org.ethereum.core.CallTransaction$Contract.parseInvocation(CallTransaction.java:285)

I guess this might not be fixed in this issue, right?

[Nashatyrev]

@jondoe1337 Thanks for issue and PR!
If you are going deeper and found new bug, then yes please file new issue with sample date (unit test would be perfect)

[Nashatyrev]

Fixed with PR #1221