A386official requested alexcrichton for a review on PR #12694.
A386official opened PR #12694 from A386official:fix/timing-duration-overflow to bytecodealliance:main:
Bug
PassTimes::total()panics with "overflow when subtracting durations" when compiling certain WASM modules. This was reported by Zed via telemetry on Windows x86 with Cranelift 33.0.2.Stack trace:
core::time::impl$3::sub (time.rs:1164) cranelift_codegen::timing::enabled::impl$0::total::closure$0 (timing.rs:174) ... cranelift_codegen::timing::enabled::PassTimes::total (timing.rs:174) wasmtime_cranelift::compiler::impl$3::compile_function (compiler.rs:284)Root Cause
PassTimes::total()computes self-time per pass asp.total - p.childusing the-operator onDuration, which panics on underflow. When timing tokens are dropped out of order (which is guarded by adebug_assertthat is elided in release builds), the accumulatedchildduration can exceedtotal, triggering the panic.The
Displayimplementation forPassTimesalready handles this edge case correctly by usingchecked_sub:if let Some(s) = time.total.checked_sub(time.child) { fmtdur(s, f)?; }But
total()was not given the same treatment.Fix
Replace
p.total - p.childwithp.total.saturating_sub(p.child)inPassTimes::total(). This is consistent with how theDisplayimpl handles the same subtraction and prevents the panic in production builds where the ordering assertion is not checked.Closes #12692
A386official requested wasmtime-compiler-reviewers for a review on PR #12694.
A386official updated PR #12694.
A386official commented on PR #12694:
Closing in favor of #12693 which addresses the same issue.
A386official closed without merge PR #12694.
Last updated: Mar 23 2026 at 16:19 UTC