5

I have a running chain which was on polkadot-v0.9.30 and updated all the libraries on to polkadot-v0.9.42

No error found while uploading but got error after updating

 panicked at 'Sensible defaults are tested to be valid; qed: <wasm:stripped>'

The error originates from

/// Create a sensible default weights system given only expected maximal block weight and the
    /// ratio that `Normal` extrinsics should occupy.
    ///
    /// Assumptions:
    ///  - Average block initialization is assumed to be `10%`.
    ///  - `Operational` transactions have reserved allowance (`1.0 - normal_ratio`)
    pub fn with_sensible_defaults(expected_block_weight: Weight, normal_ratio: Perbill) -> Self {
        let normal_weight = normal_ratio * expected_block_weight;
        Self::builder()
            .for_class(DispatchClass::Normal, |weights| {
                weights.max_total = normal_weight.into();
            })
            .for_class(DispatchClass::Operational, |weights| {
                weights.max_total = expected_block_weight.into();
                weights.reserved = (expected_block_weight - normal_weight).into();
            })
            .avg_block_initialization(Perbill::from_percent(10))
            .build()
            .expect("Sensible defaults are tested to be valid; qed")
2023-06-12 12:21:36 panicked at 'Sensible defaults are tested to be valid; qed: <wasm:stripped>', /dep/.cargo/git/checkouts/substrate-7e08433d4c370a21/569aae5/frame/system/src/limits.rs:325:9
2023-06-12 12:21:36 Proposing failed: Import failed: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
WASM backtrace:

    0: 0xfa66b - <unknown>!rust_begin_unwind
    1: 0x2df7 - <unknown>!core::panicking::panic_fmt::h6d1629d4208ae76c
    2: 0x3198 - <unknown>!core::result::unwrap_failed::h8ef12658cee03bf1
    3: 0xe0dc - <unknown>!frame_system::limits::BlockWeights::with_sensible_defaults::hddec9606e207be2d
    4: 0x70937 - <unknown>!<pallet_scheduler::pallet::Pallet<T> as frame_support::traits::hooks::OnInitialize<<T as frame_system::pallet::Config>::BlockNumber>>::on_initialize::h4b32587c5fd765a6
    5: 0x91420 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::initialize_block::hffb3eafa82bbd60b
    6: 0xa66d5 - <unknown>!Core_initialize_block

How to fix this issue ? or is there any guidance around this ?

Screemshot

Changes made for version updates

  • sp_consensus_grandpa and sc_consensus_grandpa

  • removed #[pallet::generate_store(pub(super) trait Store)] since its no longer supporting

  • Added #[pallet::call_index()]

  • Changed fn create_verifiable_credential() -> Weight { Weight::from_ref_time(10_000_000_u64) to fn revoke_did_document() -> Weight { Weight::from_parts(10_000_000_u64, 1600) }

  • In runtime/build.rs changed to

#[cfg(feature = "std")]
   {
       substrate_wasm_builder::WasmBuilder::new()
           .with_current_project()
           .export_heap_base()
           .import_memory()
           .build();
   }

Those were the some of significant changes

Did not crash the process, update went smoothly , the error message keeps popping up and blocks are not finalising

This question totally unrelated with construct_runtime_integrity_test failing. since this does not occur in tests and happens after successful runtime update

10
  • The code you link to is not the culprit in this case it is only the bearer of the bad news. Explain and examine the changes you did from 0.9.30 to 0.9.42. Are all weights updated?
    – Simson
    Commented Jun 12, 2023 at 1:07
  • So updated all the weights as per new weights
    – Kalanamith
    Commented Jun 12, 2023 at 1:14
  • @Simson updated
    – Kalanamith
    Commented Jun 12, 2023 at 1:24
  • Are you running your chain locally or are you doing a runtime upgrade?
    – Simson
    Commented Jun 12, 2023 at 2:53
  • 3
    Looks like a duplicate of construct_runtime_integrity_test failing Commented Jun 12, 2023 at 9:06

1 Answer 1

1

After digging in to version differences I found that I was missing the configuration

pub BlockWeights: frame_system::limits::BlockWeights =
        frame_system::limits::BlockWeights::with_sensible_defaults(
            Weight::from_parts(2u64 * WEIGHT_REF_TIME_PER_SECOND, u64::MAX),
            NORMAL_DISPATCH_RATIO,
        );

This causes the whole execution to panic after.

So Make sure you have updated all the runtime configuration for the version 0.9.42

parameter_types! {
    pub const BlockHashCount: BlockNumber = 2400;
    pub const Version: RuntimeVersion = VERSION;
    /// We allow for 2 seconds of compute with a 6 second average block time.
    pub BlockWeights: frame_system::limits::BlockWeights =
        frame_system::limits::BlockWeights::with_sensible_defaults(
            Weight::from_parts(2u64 * WEIGHT_REF_TIME_PER_SECOND, u64::MAX),
            NORMAL_DISPATCH_RATIO,
        );
    pub BlockLength: frame_system::limits::BlockLength = frame_system::limits::BlockLength
        ::max_with_normal_ratio(5 * 1024 * 1024, NORMAL_DISPATCH_RATIO);
    pub const SS58Prefix: u8 = 42;
}
2
  • Did you run the runtime integrity test? It should have caught that panic. Commented Jun 14, 2023 at 10:15
  • I did run all the tests
    – Kalanamith
    Commented Jun 15, 2023 at 3:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.