Execution errors
Overview
A list of possible errors returned when executing canisters.
Errors
Method not found
The canister was called with a method name not exported by that canister.
An example of this error is:
Canister has no update method 'foobar'.
To fix this error, consider:
- Checking that the method name exactly matches the name exported by the callee.
- Checking that the method type (update, query, etc...) is the same as the type of the exported method.
- The canister code of the callee has not been modified to a version that deprecates the method.
For further information on calling canisters see the smart contract docs and the IC spec.
Instruction limit exceeded
The canister reached the maximum number of allowed instructions before completing execution.
An example of this error is:
Canister exceeded the instruction limit for single message execution.
Instruction limits differ depending on the message type and can be found in the documentation on resource limits.
To fix this error, consider using tools such as the performance counter API or canbench to determine which sections of code are using significant instructions and optimize them.
Trapped
The canister encountered a WebAssembly trap.
An example of this error is:
Canister trapped: <WebAssembly error>
Some examples of WebAssembly operations that will trap are out-of-bounds accesses, integer division by zero, the unreachable instruction, etc. Further information can be found in the WebAssembly documentation.
To fix this error, consider testing the canister to see if there are any unhandled errors.
Trapped explicitly
The canister aborted execution by calling the ic0.trap API.
An example of this error is:
Canister called `ic0.trap` with message: <Canister error message>
When encountering an error, canister's may choose to fail with an error message by calling the ic0.trap API. The Rust and Motoko CDK's will insert calls to this API when panicking.
To fix this error, consider testing the canister to see if certain inputs can trigger panics.
Wasm module not found
The canister exists, but has no Wasm module installed.
An example of this error is:
Attempted to execute a message, but the canister contains no Wasm module.
Canisters can exist without having Wasm code installed. A canister will have no Wasm code if it has never been installed, or if it has been uninstalled.
To better diagnose this error use the dfx canister status command or the canister_status API to check if the canister has a module installed. If there is a module the "Module hash" field will be non-null.
To fix this error, consitder installing code using dfx deploy, or the APIs for install_code or install_chunked_code.
Out of memory
The canister was tried to request more memory than its allocation allowed during execution, causing the execution to fail.
An example of this error is:
Canister exceeded its allowed memory allocation.
There are system wide limits on the main and stable memory of each canister, as well as limits on the total memory of a subnet. This error could be triggered by any one of those limits being reached.
In addition, canisters may reserve memory using the memory-allocation setting. In this case the canister is guaranteed to be able to use up to the allocated memory, but will receive an "Out of memory" error when trying to use more than the allocated amount.
To diagnose this error use the dfx canister status command or the canister_status API to check the canister's current memory usage and memory allocation. The subnet memory usage can also be seen on the ICP dashboard.
To fix this error, consider:
- If the canister has reached its current memory allocation, try allocating more memory.
- If the canister has reached the system-wide limits for memory usage and it seems reasonable for the canister to have used 100s of GiBs, try sharding the data across multiple canisters.
- If the canister has unexpectedly reached the system-wide limits, try debugging it to see if there could be a memory leak. canbench can help with profiling memory usage.
- If the subnet is full, try moving the canister to a subnet which has more memory available.
Reserved pages for old Motoko
The canister is running an older version of Motoko which requires reserving some additional pages on the Wasm heap for upgrading and tried to allocate those reserved pages.
An example of this error is:
Canister tried to allocate pages reserved for upgrading older versions of Motoko.
Newer versions of Motoko don't require these reserved pages, so upgrading the version of Motoko used in the canister will fix the issue. dfx stores the Motoko compiler (moc) in the directory returned by dfx cache show. So the version of Motoko can be shown by running $(dfx cache show)/moc --version. This issue only occurs for versions 0.6.20 and older.
To fix this error, upgrade to the latest version of dfx which will use a newer version of Motoko.
Slice overrun
The canister tried to perform a large copy that cannot be performed in a single round.
An example of this error is:
Canister attempted to perform a large memory operation that used N instructions and exceeded the slice limit M.
In order to maintain a consistent block rate, there is a limit on the number of operations ICP can perform within a single round. A single large copy (possibly to or from stable memory, or within the main heap) could be too large to execute within a single round and cannot be automatically broken up into smaller copies.
To fix this error, inspect the canister code for locations that may be executing large copies and split them up into multiple smaller copies.
Memory access limit exceeded
The amount of data that the canister tried to read or write from stable memory exceeded the limits for a single message.
An example of this error is:
Canister exceeded memory access limits: Exceeded the limit for the number of modified pages in the stable memory in a single message execution: limit: 8388608 KB.
Although the stable memory of a canister can hold 100s of GiBs of data, each individual message needs to execute within a round and so is limited to reading and writing only a portion of that data. Current limits can be found in the page on ICP limits.
To fix this error, break up operations that read or write large regions of stable memory into multiple messages (possibly using self-calls).
Insufficient cycles in memory grow
The canister does not have enough cycles to grow its memory.
An exmaple of this error is:
Canister cannot grow memory by 65536 bytes due to insufficient cycles.
Since canister's need to pay for their memory each round, growing the memory requires that the canister have enough cycles to pay for the increased usage.
To fix this error, top up the canister with more cycles on decrease its freezing threshold.
Reserved cyles limit exceeded in memory grow
Growing the canister's memory would require reserving more cycles than allowed by the canister's reserved cycles limit.
An example of this error is:
Canister cannot grow memory by 65536 bytes due to its reserved cycles limit. The current limit (5000000000) would be exceeded by 1000000.
When subnets start to run low on memory, using up more memory requires reserving cycles to pay for the future use of that memory. Canisters have a setting that limits the number of cycles that they will reserve and this error indicates that a canister failed to grow its memory because doing so would cause the number of reserved cycles to exceed that limit.
To diagnose this error use the dfx canister status command or the canister_status API to check the canister's current reserved cycles limit. The subnet memory usage can also be seen on the ICP dashboard.
To fix this error, consider increasing the canister's reserved cycles limit, or moving to a subnet with lower memory usage.
Insufficient cycles in message memory grow
The canister doesn't have enough cycles to allocate the memory required to send a message.
An example of this error is:
Canister cannot grow message memory by 10240 bytes due to insufficient cycles.
Sending a message to another canister requires reserving space in the subnet's memory usage for the message and its response. This error indicates that a canister doesn't have enough cycles to pay for this memory usage without freezing.
To fix this error, top up the canister with more cycles on decrease its freezing threshold.
Wasm memory limit exceeded
The canister tried to grow its Wasm heap memory beyond the limit imposed by its Wasm memory limit setting.
An example of this error is:
Canister exceeded its current Wasm memory limit of 2147483648 bytes. The peak Wasm memory usage was 2147485000 bytes. If the canister reaches 4GiB, then it may stop functioning and may become unrecoverable. Please reach out to the canister owner to investigate the reason for the increased memory usage. It might be necessary to move data from the Wasm memory to the stable memory. If such high Wasm memory usage is expected and safe, then the developer can increase the Wasm memory limit in the canister settings.
Canisters may impose limits on the amount of Wasm heap memory they are allowed to use in order to prevent them from using the full 4 GiB. This is desirable because a canister that uses the full 4 GiB may to be able to upgrade if the pre-upgrade hook requires allocating more heap memory.
To diagnose this error use the dfx canister status command or the canister_status API to check the canister's Wasm memory limit. If the memory usage is unexpected, try using canbench to determine if there is a memory leak.
To fix this error, consider re-architecting the canister to use stable memory instead of heap memory or sharding the data across multiple canisters. Raising the memory limit may be another option if you are certain the canister can use more memory and still be upgradeable.
Calling a system API from the wrong mode
The canister tried to use a system API call in a message type where it isn't permitted.
An example of this error is:
Canister violated contract: "ic0.call_new" cannot be executed in non replicated query mode.
Certain system API's are only available in certain types of messages. For an overview of when each system API can be used, see the ICP spec.
This error could occur because the canister is trying to do something in a query that is only allowed in a composite query (e.g. making a call) or doing something in a composite query that is only allowed in an update (e.g. setting a timer). If this is the case, consider changing the type of call to one that allows the API.
msg_reply_data_append payload too large
The canister tried to reply with a payload that is larger than the maximum allowed response.
An example of this error is:
Canister violated contract: ic0.msg_reply_data_append: application payload size (3000000) cannot be larger than 2097152.
The response to a message cannot exceed the maximum allowed response. Consider having the canister check the size of a response before replying and truncating it or returning an error if it is too long.
msg_reject payload too large
The canister tried to reject a message with a payload that is larger than the maximum allowed response.
An example of this error is:
Canister violated contract: ic0.msg_reject: application payload size (3000000) cannot be larger than 2097152.
The string included with a rejection cannot exceed the maximum allowed response. Consider having the canister check the size of the reject string before replying and truncating it or returning a different error if it is too long.
certified_data_set payload too large
The canister tried to set some certified data which exceeds the ICP limit on certified data size.
An example of this error is:
Canister violated contract: ic0_certified_data_set failed because the passed data must be no larger than 32 bytes. Found 100 bytes.
To fix this error, consider certifying just a hash of the data instead of its full contents. Some other ideas can be found on the forum.
Canister made a call with too large method name
The canister tried to execute a call with a method name that is too long.
An example of this error is:
Canister violated contract: Size of method_name 22000 exceeds the allowed limit of 20000.
Method names are generally short (similar to function names) so it is likely a bug in the calling canister that creates a name which is too long. Consider running the canister locally and using debug printing (using Debug in Motoko or println! in Rust) to verify that the correct method name is being called.
Canister made a call with too large payload
The canister tried to make a call with a payload that exceeds ICP message size limits.
An example of this error is:
Canister violated contract: Request to xxx-xxx:foo has a payload size of 20000000, which exceeds the allowed limit of 10485760.
To fix this error, try debugging the calling canister to check that it isn't accidentally sending more data in that call than is required. If the payload construction is correct, consider taking the message size limits into account and redesign any APIs so that large amounts of data can be transfered across multiple smaller messages.
Canister made a call with too long timeout
The canister tried to make a call with a timeout that exceeds the maximum timeout allowed.
An example of this error is:
Canister violated contract: Request to xxx-xxx:foo has a timeout of {} seconds, which exceeds the allowed timeout duration.
To fix this error, check that the correct timeout is being set when making the call (noting that the timeout is denoted in seconds). If a very long timeout is really required, consider not setting a timeout at all.
Wasm module too large
The canister's Wasm module exceeds the maximum size allowed on ICP.
An example of this error is:
Canister's Wasm module is not valid: Wasm module size of 200000000 exceeds the maximum allowed size of 104857600.
To fix this error, consider shrinking or optimizing the Wasm module size using ic-wasm (shrinking is done by default when using dfx). If the canister is still too large consider removing unneeded dependencies or refactoring the logic into multiple canisters that call each other.
Wasm module duplicate exports
The canister is exporting multiple methods with the same name.
An example of this error is:
Canister's Wasm module is not valid: Wasm module has an invalid export section. Duplicate function 'foo' exported multiple times with different call types: update, query, or composite_query.
To fix this error, change the name of one of the duplicated exports.
Wasm module exports too many methods
The canister exports more methods than the maximum allowed by ICP.
An example of this error is:
Canister's Wasm module is not valid: Wasm module has an invalid export section. The number of exported functions called `canister_update <name>`, `canister_query <name>`, or `canister_composite_query <name>` exceeds 1000.
There are some limits on how a canister's Wasm modules can declare methods. To fix this error, consider consolidating the logic of multiple methods into a single method with an additional argument or an enum argument to distinguish which backend code to run. Or, consider separating the logic across multiple canisters.
Wasm module sum of exported name lengths too large
The sum of the name lengths of all exported methods methods of the canister is too large.
An example of this error is:
Canister's Wasm module is not valid: Wasm module has an invalid export section. The sum of `<name>` lengths in exported functions called `canister_update <name>`, `canister_query <name>`, or `canister_composite_query <name>` exceeds 20000.
There is a limit on the total size of exported names for a single canister. To fix this error, consider choosing shorted method names.
Wasm module too many functions
The canister's Wasm module contains more functions than ICP allows.
An example of this error is:
Canister's Wasm module is not valid: Wasm module defined 60000 functions which exceeds the maximum number allowed 50000.
One of the limits imposed by ICP is on the number of functions each Wasm module may define. In order to stay below the limit, consider using ic-wasm to remove unused functions. If the limit is still exceeded, consider splitting the logic across multiple canisters.
Wasm module too many globals
The canister's Wasm module contains more globals than ICP allows.
An example of this error is:
Canister's Wasm module is not valid: Wasm module defined 1200 globals which exceeds the maximum number allowed 1000.
One of the limits imposed by ICP is on the number of globals each Wasm module may define.
To fix this error, consider grouping globals together into a larger global structure which can be stored in the Wasm heap memory.
Wasm module function complexity too high
The canister's Wasm module contains a function which ICP rejects because it may take too long to compile.
An example of this error is:
Canister's Wasm module is not valid: Wasm module contains a function at index 7 with complexity 1300000 which exceeds the maximum complexity allowed 1000000.
Certain Wasm instructions (e.g. those involving branching or indirection) may take a long time to compile, so each function is only allowed to use them a limited number of times. This error indicates that there is a large function exceeding these limits.
To fix this error, consider breaking the large function up into multiple smaller functions.
Wasm module function too large
The canister's Wasm module contains a function which is too large.
An example of this error is:
Canister's Wasm module is not valid: Wasm module contains a function at index 7 of size 1500000 that exceeds the maximum allowed size of 1000000.
ICP limits the number of Wasm instructions that each function body is allowed to contain. This error indicates that there is a large function which exceeds this limit.
To fix this error, consider breaking the large function up into multiple smaller functions.
Wasm module code section too large
The total size of all the function bodies in the canister's Wasm module is too large.
An example of this error is:
Canister's Wasm module is not valid: Wasm module code section size of 1200000 exceeds the maximum allowed size of 10485760.
There is a limit on the total size in bytes of the code section of each canister's Wasm module. This section contains the function bodies of all the functions defined by the Wasm module.
To fix this error, consider using ic-wasm to shrink the size of the code section. If the limit is still exceeded, consider splitting the logic across multiple canisters.