nodejs/node · critical
U_MEMORY_ALLOCATION_ERROR
U_MEMORY_ALLOCATION_ERROR
Error message
icupkg: unable to allocate memory for swapping \"%s\"\n
What it means
After a successful openSwapper, pkgitems allocates `new uint8_t[pItem->length]` to hold the swapped bytes; if that returns NULL it prints the item name and exit(U_MEMORY_ALLOCATION_ERROR). With throwing new this is effectively unreachable unless pItem->length is astronomically large (corrupt length field).
Source
Thrown at deps/icu-small/source/tools/toolutil/pkgitems.cpp:105
}
length=pItem->length-itemHeaderLength;
if(pInfo->isBigEndian==U_IS_BIG_ENDIAN && pInfo->charsetFamily==U_CHARSET_FAMILY) {
bytes=pItem->data+itemHeaderLength;
} else {
UDataSwapper* ds = udata_openSwapper(static_cast<UBool>(pInfo->isBigEndian), pInfo->charsetFamily, U_IS_BIG_ENDIAN, U_CHARSET_FAMILY, &errorCode);
if(U_FAILURE(errorCode)) {
fprintf(stderr, "icupkg: udata_openSwapper(\"%s\") failed - %s\n",
pItem->name, u_errorName(errorCode));
exit(errorCode);
}
ds->printError=printError;
ds->printErrorContext=stderr;
swapped=new uint8_t[pItem->length];
if(swapped==nullptr) {
fprintf(stderr, "icupkg: unable to allocate memory for swapping \"%s\"\n", pItem->name);
exit(U_MEMORY_ALLOCATION_ERROR);
}
swap(ds, pItem->data, pItem->length, swapped, &errorCode);
pInfo=::getDataInfo(swapped, pItem->length, infoLength, itemHeaderLength, &errorCode);
bytes=swapped+itemHeaderLength;
udata_closeSwapper(ds);
}
}
private:
const Item *pItem;
const UDataInfo *pInfo;
const uint8_t *bytes;
uint8_t *swapped;
int32_t length;
};
// check a dependency ------------------------------------------------------ ***View on GitHub (pinned to 1b2de5e052)
Solutions
- Regenerate the .dat from clean source data (likely a corrupt length field).
- Sanity-check item length against the file size before trusting it.
- Raise available memory if the size is legitimately large.
- Inspect the .dat with `icupkg -l` and reject packages with implausibly large items.
Example fix
# before icupkg -x corrupt.dat # garbage length -> huge alloc -> exit 977 # after icupkg -l clean.dat && icupkg -x clean.dat # rebuild .dat from source first
Defensive patterns
Strategy: validation
Validate before calling
# reject packages whose declared item sizes look corrupt before extracting
icupkg -l "$DAT" | awk 'NR>1 && $2+0 > 1073741824 { print "implausible item size:",$0; exit 1 }' Prevention
- Sanity-check item lengths against the file size; a multi-GB item in a small .dat is corruption.
- Regenerate .dat from clean source when lengths look wrong.
- Raise available memory only after confirming the size is legitimate.
- Validate with `icupkg -l` before extracting.
When it happens
Trigger: pItem->length is huge due to a corrupt/truncated .dat header (so new requests gigabytes), or genuine heap exhaustion during the swap buffer allocation. The `if(swapped==nullptr)` check fires.
Common situations: A damaged .dat where an item's length field is garbage, causing a multi-GB allocation attempt; OOM on a constrained build host.
Related errors
- U_MEMORY_ALLOCATION_ERROR
- icupkg: udata_openSwapper(\"%s\") failed - %s\n
- U_BUFFER_OVERFLOW_ERROR
- U_INVALID_CHAR_FOUND
- U_MEMORY_ALLOCATION_ERROR
AI-assisted analysis of nodejs/node@1b2de5e052 (2026-08-13).
Data as JSON: /api/errors/8e76144801a51149.
Report an issue: GitHub.