oven-sh/bun · critical · CertError
OUT_OF_MEM
OUT_OF_MEM
Error message
OUT_OF_MEM
What it means
X509 verify result 17 (X509_V_ERR_OUT_OF_MEM): BoringSSL/X.509 verification ran out of memory while building or verifying the chain. Mapped via get_cert_error_from_no (src/http/lib.rs:1536) to CertError::OUT_OF_MEM. Unlike the sibling variants, this is a resource failure, not a trust decision.
Source
Thrown at src/http/error.rs:155
#[error("CRL_SIGNATURE_FAILURE")]
CRL_SIGNATURE_FAILURE,
#[error("CERT_NOT_YET_VALID")]
CERT_NOT_YET_VALID,
#[error("CERT_HAS_EXPIRED")]
CERT_HAS_EXPIRED,
#[error("CRL_NOT_YET_VALID")]
CRL_NOT_YET_VALID,
#[error("CRL_HAS_EXPIRED")]
CRL_HAS_EXPIRED,
#[error("ERROR_IN_CERT_NOT_BEFORE_FIELD")]
ERROR_IN_CERT_NOT_BEFORE_FIELD,
#[error("ERROR_IN_CERT_NOT_AFTER_FIELD")]
ERROR_IN_CERT_NOT_AFTER_FIELD,
#[error("ERROR_IN_CRL_LAST_UPDATE_FIELD")]
ERROR_IN_CRL_LAST_UPDATE_FIELD,
#[error("ERROR_IN_CRL_NEXT_UPDATE_FIELD")]
ERROR_IN_CRL_NEXT_UPDATE_FIELD,
#[error("OUT_OF_MEM")]
OUT_OF_MEM,
#[error("DEPTH_ZERO_SELF_SIGNED_CERT")]
DEPTH_ZERO_SELF_SIGNED_CERT,
#[error("SELF_SIGNED_CERT_IN_CHAIN")]
SELF_SIGNED_CERT_IN_CHAIN,
#[error("UNABLE_TO_GET_ISSUER_CERT_LOCALLY")]
UNABLE_TO_GET_ISSUER_CERT_LOCALLY,
#[error("UNABLE_TO_VERIFY_LEAF_SIGNATURE")]
UNABLE_TO_VERIFY_LEAF_SIGNATURE,
#[error("CERT_CHAIN_TOO_LONG")]
CERT_CHAIN_TOO_LONG,
#[error("CERT_REVOKED")]
CERT_REVOKED,
#[error("INVALID_CA")]
INVALID_CA,
#[error("PATH_LENGTH_EXCEEDED")]
PATH_LENGTH_EXCEEDED,
#[error("INVALID_PURPOSE")]View on GitHub (pinned to 8c5296ac45)
Solutions
- Raise the container/process memory limit or free memory before retrying
- Profile for leaks — the TLS verification itself needs only a few KB
- If a specific server triggers it with an enormous chain, that server is broken or hostile; avoid/fix it
- Retry once after GC/memory relief — a transient OOM clears
Defensive patterns
Strategy: retry
Validate before calling
// guard headroom before starting TLS-heavy batches
function assertMemoryHeadroom(minFreeBytes = 64 * 1024 * 1024) {
const { rss, systemMemory } = Bun.memoryUsage ? { ...Bun.memoryUsage, systemMemory: 0 } : { rss: 0, systemMemory: 0 };
const pages = Bun.syscall ? null : null; // keep it simple: rely on cgroup/container limits externally
if (rss > Number(process.env.MAX_RSS_BYTES ?? Infinity) - minFreeBytes) {
throw new Error("Insufficient memory headroom for TLS workload");
}
} Type guard
function isCertErrorCode(e: unknown, code = "OUT_OF_MEM"): e is Error & { code: string } {
return e instanceof Error && (e as any).code === code;
} Try / catch
async function fetchWithMemRetry(url: string, tries = 2) {
for (let i = 0; ; i++) {
try {
return await fetch(url);
} catch (e) {
if (i < tries && isCertErrorCode(e, "OUT_OF_MEM")) {
Bun.gc(true); // free memory, then retry once
continue;
}
throw e;
}
}
} Prevention
- Set container memory limits with headroom above observed peak RSS
- Watch for leaks with Bun.memoryUsage.rss dashboards; verification OOM is a symptom, not the cause
- Avoid/fix servers that present pathological chains (hundreds of certs)
When it happens
Trigger: TLS handshake on a process at its memory ceiling — very large chains (hundreds of intermediates, adversarial servers), or the process/container already near its RSS/cgroup limit when verification allocates.
Common situations: Containers with tight memory limits (cgroup OOM pressure), memory leaks elsewhere leaving no headroom, or malicious/broken servers presenting pathological chains.
Related errors
- UNABLE_TO_GET_ISSUER_CERT
- UNABLE_TO_GET_CRL
- UNABLE_TO_DECRYPT_CERT_SIGNATURE
- UNABLE_TO_DECRYPT_CRL_SIGNATURE
- UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY
AI-assisted analysis of oven-sh/bun@8c5296ac45 (2026-08-16).
Data as JSON: /api/errors/bb0977e52d320207.
Report an issue: GitHub.