[Bug] Failed to compile Wasm that is known to be good

Developers Command Line Tools
1

Hi guys, this morning I installed 0.4.9 and it is impossible to start, with the message below (with RUST_BACKTRACE set to full).
This is quite problematic given that 0.4.7 cannot work anymore ( dfx start produces just the following output v: 0.4.7 p: “/home/lisica/.cache/dfinity/versions/0.4.7/dfx” ).
Any hint ?

$ dfx start
⠁ Starting up the client...
binding to: V4(127.0.0.1:8000)
client: "http://localhost:8080/api"
version: 0.1.0
 Node ID: 100
  Data Center ID: 200
   Dec 08 11:53:09.985 INFO Starting nodemanager /home/lisica/.cache/dfinity/versions/0.4.9/client
version: 0.1.0
 Node ID: 100
  Data Center ID: 200
   Dec 08 11:53:09.988 INFO Dfinity Client Started
   Dec 08 11:53:09.988 INFO Existing node ID: 4630841418330328513
   StateManager: 1
    Dec 08 11:53:09.988 INFO Using path '/tmp' to manage local state
    Dec 08 11:53:09.990 CRIT Failed to compile Wasm that is known to be good: ContractViolation("Module imports function \'arg_data_size\' that is not exported by the runtime.")
thread 'main' panicked at 'Failed to compile Wasm that is known to be good: ContractViolation("Module imports function \'arg_data_size\' that is not exported by the runtime.")', state_manager/src/lib.rs:61:17
stack backtrace:
   0:     0x55fae271b234 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hb0e0f1952c2bc1d0
   1:     0x55fae27585fd - core::fmt::write::hfe07d38665f7961d
   2:     0x55fae2716fb5 - std::io::Write::write_fmt::h0207926791c1fd22
   3:     0x55fae2722b15 - std::panicking::default_hook::{{closure}}::h99af2589afc187a8
   4:     0x55fae2722843 - std::panicking::default_hook::h450385bb8efb6016
   5:     0x55fae2723218 - std::panicking::rust_panic_with_hook::h1d8ba5643aa30ffe
   6:     0x55fae2722db2 - std::panicking::continue_panic_fmt::h24c51b12d73e7f42
   7:     0x55fae2722d0c - std::panicking::begin_panic_fmt::hdc54610418bff8dd
   8:     0x55fae18a943f - ic_state_manager::StateManagerImpl::new::{{closure}}::h2553a52fab01da73
   9:     0x55fae18b2868 - ic_state_manager::checkpoint::recover_checkpoint::hb46b7e5f79b30e9c
  10:     0x55fae18a8b2f - ic_state_manager::StateManagerImpl::new::hff3efb78a2ee6030
  11:     0x55fae177e206 - ic_client::execute_context::hb2b29e7d767b4083
  12:     0x55fae1781a0e - client::main::h7dfcb582817c4f08
  13:     0x55fae1779dd1 - std::rt::lang_start::{{closure}}::h62b3729cd9eb7151
  14:     0x55fae2722c43 - std::panicking::try::do_call::h99f4b62470057fb4
  15:     0x55fae274289a - __rust_maybe_catch_panic
  16:     0x55fae2723656 - std::rt::lang_start_internal::ha2340954d561c9c7
  17:     0x55fae1782182 - main
  18:     0x7fa089e7eb8e - __libc_start_main
  19:     0x55fae174b08a - _start
  20:                0x0 - <unknown>
  Internet Computer client started...
   Dec 08 11:53:11.019 INFO Starting nodemanager /home/lisica/.cache/dfinity/versions/0.4.9/client
version: 0.1.0
 Node ID: 100
  Data Center ID: 200
   Dec 08 11:53:11.028 INFO Dfinity Client Started
   Dec 08 11:53:11.028 INFO Existing node ID: 4630841418330328513
   StateManager: 1
    Dec 08 11:53:11.029 INFO Using path '/tmp' to manage local state
    Dec 08 11:53:11.032 CRIT Failed to compile Wasm that is known to be good: ContractViolation("Module imports function \'arg_data_size\' that is not exported by the runtime.")
thread 'main' panicked at 'Failed to compile Wasm that is known to be good: ContractViolation("Module imports function \'arg_data_size\' that is not exported by the runtime.")', state_manager/src/lib.rs:61:17
2 Likes
2

Thanks Guillaume, the team will take a look.
@alexa.smith (OS is Ubuntu 18.04)

1 Like
3

@guillaumestols see here from the team: Client tried to recover from a checkpoint created by the previous version of SDK. Killing the checkpoint will fix the problem. Something like rm -rf $TMPDIR/checkpoints. We’re also currently working on a longer-term fix!

3 Likes
4

Hi Alexa, thanks for the update. I actually tried now (after a reboot) and dfx start works straightforward, so no need for the command, but it’s good to know :-).

2 Likes
5

Yes, a restart would likely clean your temporary folder. We hope to have a flag that does it for you soon™.

3 Likes