Debug doesn't print anything

[forgetso]

When I run the node without debug logging I get the usual logs.

(base) ➜ protocol git:(captcha_solution_key) ✗ substrate-contracts-node --dev --tmp

2021-10-29 20:49:05 Running in --dev mode, RPC CORS has been disabled.
2021-10-29 20:49:05 Substrate Contracts Node
2021-10-29 20:49:05 ✌️ version 0.1.0-3f63edf-x86_64-linux-gnu
2021-10-29 20:49:05 ❤️ by Parity Technologies [email protected], 2021-2021
2021-10-29 20:49:05 📋 Chain specification: Development
2021-10-29 20:49:05 🏷 Node name: late-mother-4360

When I run with this:

(base) ➜ protocol git:(captcha_solution_key) ✗ substrate-contracts-node --dev --tmp -lerror,runtime::contracts=debug

Nothing is printed even though I am making RPC calls to the contract.

Version is substrate-contracts-node 0.1.0-3f63edf-x86_64-linux-gnu

EDIT

I am building my contract using --release flag as I otherwise get CodeTooLarge when instantiating it. Presumably, this will silence the debug messages as per the docs?

I need to debug the contract as I'm getting a ContractTrapped when calling it from polkadot-js. The ink unit tests don't highlight any issues and the contract balance is 10.0000 kUnit.

Ink version is 3.0.0-rc6.

[forgetso]

The solution to the ContractTrapped error was to update all my dependencies.

e.g.

    "@polkadot/api": "^6.5.2",
    "@polkadot/api-contract": "^6.5.2",
    "@polkadot/types": "^6.5.2",
    "@polkadot/util": "^7.6.1"

So many fast moving parts in this stuff!

It would still be good to understand why the node outputs nothing.

[cmichi]

@forgetso You're right that --release silences the output. Can you identify why your contract is so big?

We observe that this typically happens because some third-party crate is included in the Cargo.toml and subsequently bloats the size up.

[forgetso]

Hi @cmichi , I'm not sure what that would be. The contract toml is the same as most of the examples in the ink repo. You can view it here.

[cmichi]

@forgetso Your contract is making heavy use of ink!'s HashMap ‒ this is totally fine, but that data structure takes a lot of space and this altogether results in the large contract size. We are currently working on a space-efficient data structure Mapping, which will improve this by a lot (this is the issue for it, we will soon merge it).

Until then, in order to debug your contract, you could comment out the events ‒ we know that the event logic takes up a lot of space and my hunch is that this could bring your code size sufficiently down.

[forgetso]

Thanks for the info. I'll look into changing to Mapping when it's released. If I need to debug before then I'll try silencing the events.

[forgetso]

Hi, I'm reopening this as I now have a contract built in debug mode and I still cannot get the contracts node to print anything out.

Is it normal for nothing to be printed by the node when run with this command or should it print details of blocks being produced?

./target/debug/substrate-contracts-node --dev --tmp -lerror,runtime::contracts=debug

I have a debug print in my constructor but it still doesn't print anything.

I'm able to deploy the contract so I'm assuming the constructor function must run ok.

Thanks!

[cmichi]

I have a debug print in my constructor but it still doesn't print anything.

@forgetso Sorry for the late reply. This is an unfortunate bug of the UI's:

• Canvas UI: Execute dry-run RPC of constructor before deployment of a contract canvas-ui#108
• polkadot-js: Make use of the contracts_instantiate RPC polkadot-js/apps#5338
• Substrate Contracts Explorer: Dry run instantiate use-ink/contracts-ui#132

So tl;dr: ink_env::debug_println! currently only shows up on the console if it appears in an #[ink(message)].

Alternatives for you would be that you either execute the RPC call manually or e.g. save the debug information from your constructor to your contract's storage and then create an ink! message show_debug_info() which prints it.

[forgetso]

Thanks @cmichi. Is it also true that debug only prints on read and not execute? I only seem to receive debug messages when reading the contract functions.

[cmichi]

Thanks @cmichi. Is it also true that debug only prints on read and not execute? I only seem to receive debug messages when reading the contract functions.

@forgetso Sorry, only seeing this now, your question somehow drowned in a sea of notifications after being back from vacation.

What do you mean with read and execute? I would guess that with read you mean opening the UI dialog for the method, without actually submitting a transaction. In this case the UI makes an RPC in the background to dry-run the transaction, this will make debug messages appear on the terminal. This dry-run is used to determine, among other things, what the UI displays as "max gas" value. If you actually submit a transaction no debug messages will be printed.

Currently this printing of debug messages only works for ink! messages, not for constructors. This is only a UI limitation though, which will be fixed as soon as constructors are dry-run as well (polkadot-js/apps#5338, use-ink/contracts-ui#132).

Did you manage to get debug output on the terminal by now?

[forgetso]

No problem about the delay. Hope you had a nice holiday!

By read I mean queries and not transactions. So yes I was referring to the UI dialog. For whatever reason, I was only getting debug printed out when running queries and not transactions (all in messages). Recently, I've started to get debug for both so it's magically resolved itself :) (although I am using a substrate full node now)

When debugging this I started using substrate full node and changed the code so that the retval was printed out via debug

			if let Ok(retval) = &output.result {
				log::debug!(
					target: "runtime::contracts",
					"Retval: {:?}",
					retval,
				);
				if retval.did_revert() {
					output.result = Err(<Error<T>>::ContractReverted.into());
				}
			}

This gave me

The output is flags: REVERT, data: Bytes([1, 12])

And someone helpfully pointed out that this is the 13th error in your Error enum of the Result

I know this is now off-topic, but is there any plan to propagate these errors through to the API as part of ContractReverted or is it not possible to read the Error enum inside the wasm?