Wasm Serialization check seems to use hardcoded default instead of configurable value

[systemzax]

As I was attempting to deploy a (rather) large contract with several include headers statements, I received the "Too many function defs" error message.

Here is where this check is evaluated from what I can tell :

https://github.com/AntelopeIO/leap/blob/01b128e819e6d4bac873fb3c3ae6249be5360ba5/libraries/wasm-jit/Source/WASM/WASMSerialization.cpp#L615

And this points to a constexpr set to 1024 :

https://github.com/AntelopeIO/leap/blob/01b128e819e6d4bac873fb3c3ae6249be5360ba5/libraries/chain/include/eosio/chain/wasm_eosio_constraints.hpp#L14

However, the wasm_parameters struct and the "cleos get consensus_parameters" indicate "max_section_elements": 8192.

I wonder if this is a leftover artefact due to an oversight, and should indeed be checking the wasm_parameters config instead of the hardcoded limit.

[spoonincode]

Did you activate CONFIGURABLE_WASM_LIMITS2? It appears cleos get consensus_parameters returns a wasm_config reflective of post-CONFIGURABLE_WASM_LIMITS2 activation, even when CONFIGURABLE_WASM_LIMITS2 hasn't been activated. (I'm not sure how much to consider that behavior a defect on first take.. the problem is post-CONFIGURABLE_WASM_LIMITS2 limits aren't 1:1 to those prior to to activation... it's clearly deceptive, but would a better alternative to be not to include wasm_config here prior to activation :thinking: )

[systemzax]

Ah, that would explain it then. After activating the feature, I was able to deploy the contract, presumably because the max section elements is now effectively 8192 as reported via the get consensus_parameters API. Thanks!

[bhazzard]

Since this protocol feature is activated on most chains, this one mostly affects folks spinning up test chains.

The most direct path is probably to simply not include wasm_config if the CONFIGURABLE_WASM_LIMITS2 protocol feature is not activated.