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

  1. Regenerate the .dat from clean source data (likely a corrupt length field).
  2. Sanity-check item length against the file size before trusting it.
  3. Raise available memory if the size is legitimately large.
  4. 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

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


AI-assisted analysis of nodejs/node@1b2de5e052 (2026-08-13). Data as JSON: /api/errors/8e76144801a51149. Report an issue: GitHub.