U_MEMORY_ALLOCATION_ERROR

U_MEMORY_ALLOCATION_ERROR

Error message

pkgdata: Error: Unable to allocate tmp buffer size: %d\n

What it means

uprv_malloc failed to allocate the tmp buffer used to build srcDir + separator + resource path for a file-list entry. pkgdata exits with U_MEMORY_ALLOCATION_ERROR. The buffer size printed is strlen(srcDir)+strlen(s)+5, so this is almost always genuine memory exhaustion or an absurdly large path, not a logic bug.

Source

Thrown at deps/icu-small/source/tools/pkgdata/pkgdata.cpp:2136

                    if(lineNext) {
                        *lineNext = 0; /* terminate at space */
                        lineNext++;
                    }
                }

                /* add the file */
                s = const_cast<char*>(getLongPathname(linePtr));

                /* normal mode.. o->files is just the bare list without package names */
                o->files = pkg_appendToList(o->files, &tail, uprv_strdup(linePtr));
                if(uprv_pathIsAbsolute(s) || s[0] == '.') {
                    fprintf(stderr, "pkgdata: Error: absolute path encountered. Old style paths are not supported. Use relative paths such as 'fur.res' or 'translit%cfur.res'.\n\tBad path: '%s'\n", U_FILE_SEP_CHAR, s);
                    exit(U_ILLEGAL_ARGUMENT_ERROR);
                }
                /* The +5 is to add a little extra space for, among other things, PKGDATA_FILE_SEP_STRING */
                tmpLength = static_cast<int32_t>(uprv_strlen(o->srcDir) + uprv_strlen(s) + 5);
                if ((tmp = static_cast<char*>(uprv_malloc(tmpLength))) == nullptr) {
                    fprintf(stderr, "pkgdata: Error: Unable to allocate tmp buffer size: %d\n", tmpLength);
                    exit(U_MEMORY_ALLOCATION_ERROR);
                }
                uprv_strcpy(tmp, o->srcDir);
                uprv_strcat(tmp, o->srcDir[uprv_strlen(o->srcDir)-1] == U_FILE_SEP_CHAR ? "" : PKGDATA_FILE_SEP_STRING);
                uprv_strcat(tmp, s);
                o->filePaths = pkg_appendToList(o->filePaths, &tail2, tmp);
                linePtr = lineNext;
            } /* for each entry on line */
        } /* for each line */
        T_FileStream_close(in);
    } /* for each file list file */
}

/* Helper for pkg_getPkgDataPath() */
#if U_HAVE_POPEN
static UBool getPkgDataPath(const char *cmd, UBool verbose, char *buf, size_t items) {
    icu::CharString cmdBuf;
    UErrorCode status = U_ZERO_ERROR;

View on GitHub (pinned to 1b2de5e052)

Solutions

Reduce parallelism (lower make -j) to cut peak memory.
Raise the container/cgroup memory limit for the build.
Inspect srcDir for corruption or an unterminated string.
Run the build on a host with more RAM or add swap.

Example fix

# before: oversubscribed parallelism on limited box
make -j32

# after: sane parallelism for available RAM
make -j4

Defensive patterns

Strategy: fallback

Validate before calling

// Nothing in user input reliably prevents OOM, but you can sanity-check srcDir length and memory.
#include <string.h>
#include <sys/resource.h>
bool saneSrcDirAndMemory(const char *srcDir) {
    if (!srcDir || strlen(srcDir) > 4096) return false;
    struct rlimit rl;
    if (getrlimit(RLIMIT_AS, &rl) == 0 && rl.rlim_cur != RLIM_INFINITY && rl.rlim_cur < (256ull*1024*1024))
        return false; // address space too small for a data build
    return true;
}

Prevention

Lower make -j to reduce peak memory.
Raise container/cgroup memory limits for data builds.
Keep srcDir a normal-length path to avoid size weirdness.
Add swap or build on a host with more RAM.

When it happens

Trigger: The build process has exhausted available memory (large parallel make, chroot with low rlimits), or srcDir/s contain a path so long the size overflows int32_t into a negative/huge value passed to a tiny malloc. exit(U_MEMORY_ALLOCATION_ERROR) follows immediately.

Common situations: Running a huge ICU data build under cgroups/container memory limits; a corrupted srcDir pointer producing a multi-GB strlen; -jN parallelism set far above RAM.

Related errors

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