mudler/LocalAI · critical

Failed to allocate memory for resized image\n

Error message

Failed to allocate memory for resized image\n

What it means

Hard error in the img2img resize step: malloc(height * width * 3) for the destination buffer returned NULL because the requested width x height is too large for available memory. The input buffer is freed and generation aborts with code 1. It is purely an allocation-size problem, not a model problem.

Source

Thrown at backend/go/stablediffusion-ggml/cpp/gosd.cpp:856

        int img_height = 0;
        input_image_buffer = stbi_load(src_image, &img_width, &img_height, &c, 3);
        if (input_image_buffer == NULL) {
            fprintf(stderr, "Failed to load input image from '%s'\n", src_image);
            return 1;
        }
        if (c < 3) {
            fprintf(stderr, "Input image must have at least 3 channels, got %d\n", c);
            free(input_image_buffer);
            return 1;
        }

        // Resize input image if dimensions don't match
        if (img_width != width || img_height != height) {
            fprintf(stderr, "Resizing input image from %dx%d to %dx%d\n", img_width, img_height, width, height);

            uint8_t* resized_image_buffer = (uint8_t*)malloc(height * width * 3);
            if (resized_image_buffer == NULL) {
                fprintf(stderr, "Failed to allocate memory for resized image\n");
                free(input_image_buffer);
                return 1;
            }

            stbir_resize(input_image_buffer, img_width, img_height, 0,
                         resized_image_buffer, width, height, 0, STBIR_TYPE_UINT8,
                         3, STBIR_ALPHA_CHANNEL_NONE, 0,
                         STBIR_EDGE_CLAMP, STBIR_EDGE_CLAMP,
                         STBIR_FILTER_BOX, STBIR_FILTER_BOX,
                         STBIR_COLORSPACE_SRGB, nullptr);

            free(input_image_buffer);
            input_image_buffer = resized_image_buffer;
        }

        p->init_image = {(uint32_t)width, (uint32_t)height, 3, input_image_buffer};
        p->strength = strength;
        fprintf(stderr, "Using img2img with strength: %.2f\n", strength);

View on GitHub (pinned to 44413a9d06)

Solutions

  1. Reduce width/height in the request to a value the process can afford (bytes needed = width*height*3 plus model memory)
  2. Raise the container/process memory limit or free other loaded models first
  3. Sanity-cap dimensions at the API layer so clients cannot request absurd sizes

Example fix

// before
width = 8192; height = 8192;  // 8192*8192*3 = 192MB buffer, may fail

// after
width = 2048; height = 2048;  // ~12.6MB buffer
Defensive patterns

Strategy: validation

Validate before calling

// Go caller: cap dimensions by affordable allocation size
const maxPixels = 2048 * 2048
if req.Width <= 0 || req.Height <= 0 || req.Width*req.Height > maxPixels {
    return fmt.Errorf("dimensions %dx%d exceed limit %d megapixels", req.Width, req.Height, maxPixels/1_000_000)
}

Prevention

When it happens

Trigger: Requesting output dimensions far larger than the input image (e.g. 4096x4096 upscale in img2img) on a memory-constrained host or inside a container with a low memory limit; integer-overflow-sized dimensions could also yield absurd allocations.

Common situations: See trigger scenarios.

Related errors


AI-assisted analysis of mudler/LocalAI@44413a9d06 (2026-08-15). Data as JSON: /api/errors/b5a75f50ab54f544. Report an issue: GitHub.