Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure that we are still sending large messages over the bridge #2015

Closed
Tracked by #2430
svyatonik opened this issue Apr 3, 2023 · 4 comments · Fixed by #2064 or #2103
Closed
Tracked by #2430

Ensure that we are still sending large messages over the bridge #2015

svyatonik opened this issue Apr 3, 2023 · 4 comments · Fixed by #2064 or #2103
Assignees
Labels
A-bug Something isn't working P-Relay

Comments

@svyatonik
Copy link
Contributor

At our test deployments we generate max-size messages sometimes. It is generated here:
https://github.com/paritytech/parity-bridges-common/blob/master/relays/bin-substrate/src/cli/encode_message.rs#L73

We need to check, whether they are actually transferred over the bridge after #1983 . Now an XCM message needs to have a special prefix to be sent to the message lane and it seems this large message doesn't have it.

@svyatonik svyatonik added A-bug Something isn't working P-Relay labels Apr 3, 2023
@svyatonik svyatonik added this to the When Thou Have Spare Hour milestone Apr 3, 2023
@svyatonik svyatonik self-assigned this Apr 3, 2023
@svyatonik svyatonik reopened this Apr 26, 2023
@svyatonik
Copy link
Contributor Author

svyatonik commented Apr 26, 2023

2023-04-26 10:54:30.095 DEBUG tokio-runtime-worker sc_basic_authorship::basic_authorship: [Parachain] [0x87d8eb9191dbec45a47c848bbfe41dfdc902ef1c664c977a2dba0cb2a3fdd20b] Invalid transaction: Error at calling runtime api: Execution failed: Execution aborted due to trap: host code panicked while being called by the runtime: Failed to allocate memory: "Requested allocation size is too large"
WASM backtrace:
error while executing at wasm backtrace:
    0: 0x20daff - <unknown>!sp_io::allocator::extern_host_function_impls::malloc::hd4775bf217cf74fb
    1: 0xf3952 - <unknown>!alloc::raw_vec::finish_grow::h4616ce65be0fb092
    2: 0xf51d1 - <unknown>!alloc::raw_vec::RawVec<T,A>::reserve_for_push::hcb079bd341241880
    3: 0x39678 - <unknown>!parity_scale_codec::codec::decode_vec_with_len::h4e6a49b3fb610851
    4: 0x1085ce - <unknown>!xcm::_::<impl parity_scale_codec::codec::Decode for xcm::VersionedXcm<RuntimeCall>>::decode::ha51cc4dd551adc0e
    5: 0xb8bac - <unknown>!<xcm_builder::universal_exports::BridgeBlobDispatcher<Router,OurPlace> as xcm_builder::universal_exports::DispatchBlob>::dispatch_blob::h7f4a2bb7671af2a9
    6: 0x1af67c - <unknown>!<bridge_runtime_common::messages_xcm_extension::XcmBlobMessageDispatch<SourceBridgeHubChain,TargetBridgeHubChain,BlobDispatcher,Weights> as bp_messages::target_chain::MessageDispatch<<SourceBridgeHubChain as bp_runtime::chain::Chain>::AccountId>>::dispatch::h4aded93477bd5e67
    7: 0xbfcc1 - <unknown>!pallet_bridge_messages::inbound_lane::InboundLane<S>::receive_message::h4f4ec90cbb6d4945
    8: 0x15c4b7 - <unknown>!frame_support::storage::transactional::with_storage_layer::h1846f9c70967c1cc
    9: 0xcf2f3 - <unknown>!<pallet_bridge_messages::pallet::Call<T,I> as frame_support::traits::dispatch::UnfilteredDispatchable>::dispatch_bypass_filter::{{closure}}::hb177e5f889e78f6a
   10: 0xd1a68 - <unknown>!environmental::local_key::LocalKey<T>::with::h101b9f88c3a85eed
   11: 0x194a17 - <unknown>!<rialto_parachain_runtime::RuntimeCall as frame_support::traits::dispatch::UnfilteredDispatchable>::dispatch_bypass_filter::h878ecdf09ad0d485
   12: 0x196558 - <unknown>!<rialto_parachain_runtime::RuntimeCall as sp_runtime::traits::Dispatchable>::dispatch::h88923c4aa4b58671
   13: 0xff863 - <unknown>!<sp_runtime::generic::checked_extrinsic::CheckedExtrinsic<AccountId,Call,Extra> as sp_runtime::traits::Applyable>::apply::he461cb20672a522b
   14: 0x1a83ec - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::apply_extrinsic::hcc6013e452935110
   15: 0x181d34 - <unknown>!BlockBuilder_apply_extrinsic

@serban300
Copy link
Collaborator

The problem doesn't reproduce when using native execution . It occurs only when running with --execution wasm. That's probably why it doesn't occur on millau and rialto.

And more specifically it occurs when decoding the XCM ClearOrigin instructions vec here.

The problem is that mem::size_of::<Instruction<Call>>() is 1472. And if we send for example 30000 ClearOrigin instructions it tries to allocate 30000 * 1472 =~ 44mil bytes + probably some buffer =~ 60mil bytes total which goes beyond the wasm VM limits.

The size of Instruction<Call> enum should be the size of it's biggest variant, but still 1472 seems huge. Trying to understand why so much.

@serban300
Copy link
Collaborator

The size of Instruction<Call> is actually 1427:

  • The size of NetworkId is 48 (this is the biggest variant = 8 (discriminator) + 8 (u64) + 32 ([u8; 32]))
  • The size of Junction is 88 (this is the biggest variant = 8 (discriminator) + 48 (NetworkId) + 32 ([u8; 32]))
  • The size of Junctions is 704 (this is the biggest variant = 88 (Junction) * 8)
  • MultiLocation = 712
    ...
  • MultiAssetFilter = 720
  • Instruction<Call> has variants of this form that contain both MultiLocation and MultiAssetFilter. And when adding up everything => 1472

The issue didn't reproduce with native execution probably because in the native environment we can allocate enough memory.

We need to have a different approach for sending max-size messages. Maybe fix the old one.

@serban300
Copy link
Collaborator

serban300 commented May 3, 2023

Fixed by #2103

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment