I have a Sway contract that compiles to be of size 824.216 Kb (quite large) with the Beta-4 toolchain. When I transition to Beta-5, I get the following error, and my contract no longer compiles.
thread 'main' panicked at sway-core/src/asm_lang/allocated_ops.rs:716:23:
Unable to offset into the data section more than 2^12 bits. Unsupported data section length.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Here’s the stack backtrace with RUST_BACKTRACE=full:
thread 'main' panicked at sway-core/src/asm_lang/allocated_ops.rs:716:23:
Unable to offset into the data section more than 2^12 bits. Unsupported data section length.
stack backtrace:
0: 0x103c6a89c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h298c9ab285ff3934
1: 0x103c8ce98 - core::fmt::write::h4e276abdb6d0c2a1
2: 0x103c66608 - std::io::stdio::_eprint::hacf0f815ff08f81b
3: 0x103c6a6d8 - <std::time::SystemTimeError as core::fmt::Display>::fmt::ha84dff9814e351ac
4: 0x103c6bc68 - std::panicking::default_hook::ha6550ffe49b63df1
5: 0x103c6b9b0 - std::panicking::default_hook::ha6550ffe49b63df1
6: 0x103c6c090 - std::panicking::rust_panic_with_hook::hddb0e884a202de7c
7: 0x103c6bf6c - <std::panicking::begin_panic_handler::StaticStrPayload as core::panic::PanicPayload>::take_box::h172fd006fbea5e8c
8: 0x103c6ad04 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h298c9ab285ff3934
9: 0x103c6bd2c - _rust_begin_unwind
10: 0x103d03218 - core::panicking::panic_fmt::h4d5168028d4c43c7
11: 0x103629778 - <sway_core::asm_lang::allocated_ops::AllocatedOp as core::fmt::Display>::fmt::h864bc9b7d6f7f2e4
12: 0x103629210 - <sway_core::asm_lang::allocated_ops::AllocatedOp as core::fmt::Display>::fmt::h864bc9b7d6f7f2e4
13: 0x1035b4424 - <alloc::vec::Vec<sway_core::asm_generation::miden_vm::miden_vm_asm_builder::miden_op::DirectOp> as sway_core::asm_generation::miden_vm::miden_vm_asm_builder::ToMidenBytecode>::to_bytecode::h320b15fe9ce76bd2
14: 0x1036adb20 - sway_core::asm_to_bytecode::h437eef83a4947f8d
15: 0x102eab794 - forc_pkg::pkg::compile::h3e0c0b967e403972
16: 0x102eb17b4 - forc_pkg::pkg::build::h1aa0adc2f9e97f5b
17: 0x102eadca0 - forc_pkg::pkg::build_with_options::h69fe2ab27f2c724e
18: 0x102ddc4b0 - forc::ops::forc_build::build::he8ef4f0d8e0eea1b
19: 0x102dc4d1c - forc::cli::commands::build::exec::haaeb09a273b59986
20: 0x102d40e84 - __mh_execute_header
21: 0x102d4fb14 - __mh_execute_header
22: 0x102d54aa4 - __mh_execute_header
23: 0x102d4fc5c - __mh_execute_header
24: 0x102d53fa0 - __mh_execute_header
25: 0x103c5e614 - std::rt::lang_start_internal::h5b246d44f1526226
26: 0x102d53f84 - __mh_execute_header
27: 0x102d54b90 - _main
Is this a bug, or has the contract code size been reduced from the ~16.7 mb limit?
Do you still get the same issue if you compile with --release? beta-5 is a lot less aggressive in the debug profile (to help debuggers) so if you have a huge contract you will benefit from turning optimizations on.
It looks like you’re compiling for MidenVM but the thread you link in the OP is talking about the FuelVM specs. Which one are you actually targetting here?
There’s not much I can really do with just this stack trace and no source. Maybe if you could identify the exact version of Sway that introduces the problem, that might help narrow it down?
right, not sure what MidenVM is, but here’s what I get with fuelup show. Targetting Beta-5 for Fuel. Quite literally using the default command: forc build (forc build --release yields the same results)
Okay there’s a bunch of problems here: you have beta-4 selected, not beta-5.
And the backtrace you gave contains this:
13: 0x1035b4424 - <alloc::vec::Vec<sway_core::asm_generation::miden_vm::miden_vm_asm_builder::miden_op::DirectOp> as sway_core::asm_generation::miden_vm::miden_vm_asm_builder::ToMidenBytecode>::to_bytecode::h320b15fe9ce76bd2
Which means that you must, somehow, have the midenvm target selected instead of the fuel default one.
What happens if you force it with --build-target fuel? What happens if you compile with the beta-5-aarch64-apple-darwin toolchain?
What does your Forc.toml look like?
you are right, I sent you the Beta-4 toolchain fuelup show output as I’ve been using that as an alternative.
I get the same error with forc build --build-target fuel and forc build --release --build-target fuel (it somehow appears that midenvm target is being selected regardless even with no input from my side)
thread 'main' panicked at sway-core/src/asm_lang/allocated_ops.rs:716:23:
Unable to offset into the data section more than 2^12 bits. Unsupported data section length.
stack backtrace:
0: 0x1031e289c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h298c9ab285ff3934
1: 0x103204e98 - core::fmt::write::h4e276abdb6d0c2a1
2: 0x1031de608 - std::io::stdio::_eprint::hacf0f815ff08f81b
3: 0x1031e26d8 - <std::time::SystemTimeError as core::fmt::Display>::fmt::ha84dff9814e351ac
4: 0x1031e3c68 - std::panicking::default_hook::ha6550ffe49b63df1
5: 0x1031e39b0 - std::panicking::default_hook::ha6550ffe49b63df1
6: 0x1031e4090 - std::panicking::rust_panic_with_hook::hddb0e884a202de7c
7: 0x1031e3f6c - <std::panicking::begin_panic_handler::StaticStrPayload as core::panic::PanicPayload>::take_box::h172fd006fbea5e8c
8: 0x1031e2d04 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h298c9ab285ff3934
9: 0x1031e3d2c - _rust_begin_unwind
10: 0x10327b218 - core::panicking::panic_fmt::h4d5168028d4c43c7
11: 0x102ba1778 - <sway_core::asm_lang::allocated_ops::AllocatedOp as core::fmt::Display>::fmt::h864bc9b7d6f7f2e4
12: 0x102ba1210 - <sway_core::asm_lang::allocated_ops::AllocatedOp as core::fmt::Display>::fmt::h864bc9b7d6f7f2e4
13: 0x102b2c424 - <alloc::vec::Vec<sway_core::asm_generation::miden_vm::miden_vm_asm_builder::miden_op::DirectOp> as sway_core::asm_generation::miden_vm::miden_vm_asm_builder::ToMidenBytecode>::to_bytecode::h320b15fe9ce76bd2
14: 0x102c25b20 - sway_core::asm_to_bytecode::h437eef83a4947f8d
15: 0x102423794 - forc_pkg::pkg::compile::h3e0c0b967e403972
16: 0x1024297b4 - forc_pkg::pkg::build::h1aa0adc2f9e97f5b
17: 0x102425ca0 - forc_pkg::pkg::build_with_options::h69fe2ab27f2c724e
18: 0x1023544b0 - forc::ops::forc_build::build::he8ef4f0d8e0eea1b
19: 0x10233cd1c - forc::cli::commands::build::exec::haaeb09a273b59986
20: 0x1022b8e84 - __mh_execute_header
21: 0x1022c7b14 - __mh_execute_header
22: 0x1022ccaa4 - __mh_execute_header
23: 0x1022c7c5c - __mh_execute_header
24: 0x1022cbfa0 - __mh_execute_header
25: 0x1031d6614 - std::rt::lang_start_internal::h5b246d44f1526226
26: 0x1022cbf84 - __mh_execute_header
27: 0x1022ccb90 - _main
This is all very odd.
beta-5 is supposed to use forc version 0.50.0.
I know neither how you got an older version nor why it seems to want to compile for the wrong target.
I must say, I’ve never encountered anything quite like this. I think you may want to delete the whole toolchain and reinstall a clean one because evidently something is going very wrong here.
i’ve reinstalled the toolchain (including fuelup) and it’s still an issue. When I try to use fuelup toolchain install latest and fuelup toolchain install beta-5, they are both installing forc version 0.49.1 which I understand is the buggy version. Any idea how I can force download v0.50.0?
yes, no luck. I’ll keep using Beta-4 in the meantime as late as I can, or till I’m able to use the latest version of forc (>=v0.50.0). Thanks for your help.
Alright, somehow I’m able to compile now both with Beta-5 and latest toolchain, BUT I’m not able to deploy said contracts with either the generated types (AbiFactory, and AbiHex), or the ContractFactory method. This is the error I get: FuelError: Invalid u16, too many bytes.
The traceback:
FuelError: Invalid u16, too many bytes.
at NumberCoder.encode (node_modules/@fuel-ts/abi-coder/src/coders/number.ts:55:13)
at TransactionCreateCoder.encode (node_modules/@fuel-ts/transactions/src/coders/transaction.ts:206:39)
at TransactionCoder.encode (node_modules/@fuel-ts/transactions/src/coders/transaction.ts:372:40)
at CreateTransactionRequest.toTransactionBytes (node_modules/@fuel-ts/providers/src/transaction-request/transaction-request.ts:189:35)
at CreateTransactionRequest.byteSize (node_modules/@fuel-ts/providers/src/transaction-request/transaction-request.ts:518:17)
at CreateTransactionRequest.calculateMinGas (node_modules/@fuel-ts/providers/src/transaction-request/transaction-request.ts:538:25)
at _Provider.getTransactionCost (node_modules/@fuel-ts/providers/src/provider.ts:810:39)
at ContractFactory.deployContract (node_modules/@fuel-ts/contract/src/contract-factory.ts:149:35)
at /Users/sluzhba/Documents/Dev/Burra Labs/ruscet-contracts/tests/core/Tester.test.ts:87:22
at step (tests/core/Tester.test.ts:33:23)
My guess is that there’s something in my contract that is causing this error, but can’t debug effectively because this contract file is ~2500 lines of code; but it appears that the error (too many bytes is loosely related to unable to offest [...] more than 2^12 bits. Maybe the contract is too big?