BoundaryML/baml · critical

failed to allocate bigint field `{field_name}`: {p}

Error message

failed to allocate bigint field `{field_name}`: {p}

What it means

Generated struct-copy code panics when try_alloc_bigint fails while copying a `bigint` field into a VM value. Bigints are heap-allocated and allocation is fallible (the value may exceed MAX_BIGINT_BITS); since `to_value` has no error channel, the failure panics with the VmPanic::AllocFailure report rather than silently dropping the overflow. The panic intentionally prints only the panic reason, never the huge number itself.

Source

Thrown at baml_language/crates/baml_builtins2_codegen/src/codegen.rs:652

        }
        // `to_value` has no error channel (`fn to_value(self, vm) -> Value`),
        // so an out-of-i63 native i64 reaches this path only when caller-side
        // Rust constructed a struct field that violates the i63 BAML
        // contract. Fail loudly in *both* debug and release rather than
        // truncating silently via `Value::int`'s `debug_assert`.
        BamlType::Int => format!(
            "bex_vm_types::Value::try_int(self.{field_name}).unwrap_or_else(|| panic!(\
                \"`{field_name}: int` is outside BAML int range [{{}}, {{}}], got {{}}\", \
                bex_vm_types::Value::INT_MIN, bex_vm_types::Value::INT_MAX, self.{field_name}))"
        ),
        // Bigints are always heap-allocated, and allocation is fallible (the
        // value may exceed `MAX_BIGINT_BITS`). `to_value` has no error channel,
        // so — like the `int` range case above — fail loudly rather than
        // silently dropping the overflow. The panic reports the bit count from
        // `VmPanic::AllocFailure` (`{p}`), never the bigint itself, which could
        // be millions of digits long.
        BamlType::Bigint => format!(
            "vm.try_alloc_bigint(self.{field_name}).unwrap_or_else(|p| panic!(\
                \"failed to allocate bigint field `{field_name}`: {{p}}\"))"
        ),
        BamlType::Float => {
            format!("bex_vm_types::Value::object(vm.alloc_float(self.{field_name}))")
        }
        BamlType::Bool => format!("bex_vm_types::Value::bool(self.{field_name})"),
        BamlType::Null => "bex_vm_types::Value::NULL".to_string(),
        // String, List, Map, Optional, Generic, Named, Media — already a Value
        _ => format!("self.{field_name}"),
    }
}

// ============================================================================
// Naming helpers
// ============================================================================

fn to_pascal_case(s: &str) -> String {
    let mut chars = s.chars();

View on GitHub (pinned to bd85ce9dee)

Solutions

  1. Check the bigint's bit length (bits()) against MAX_BIGINT_BITS before constructing the struct.
  2. Truncate or reduce the value's magnitude at the source computation.
  3. Ensure sufficient memory is available if the failure is OOM-driven.

Example fix

// before
MyStruct { big: giant_bigint }
// after
if giant_bigint.bits() > MAX_BIGINT_BITS { /* reduce or reject */ }
MyStruct { big: giant_bigint }
Defensive patterns

Strategy: validation

Validate before calling

fn allocatable(v: &BigInt) -> bool { v.bits() <= MAX_BIGINT_BITS }

Try / catch

// This is a panic, not a Result; check size before constructing
if !allocatable(&v) { /* reduce magnitude or reject upstream */ }

Prevention

When it happens

Trigger: emit_copy_struct -> copy_field_to_value generating `vm.try_alloc_bigint(self.field).unwrap_or_else(|p| panic!(...))` for a bigint field whose bit count exceeds MAX_BIGINT_BITS.

Common situations: Computing astronomically large exponents/products in Rust and passing them as BAML bigint fields; host memory exhaustion during allocation.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors


AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/a3746a6cd66d1626. Report an issue: GitHub.