DrKLO/Telegram · error

Memory allocation failure!

Error message

Memory allocation failure!

What it means

jpegyuv allocates the YUV output buffer with malloc(yuv_size) at jpegyuv.c:99, where yuv_size = luma_width*luma_height + 2*chroma_width*chroma_height. If malloc returns NULL, the image is too large for available memory. The program closes the JPEG file, prints the error, and returns 1.

Source

Thrown at TMessagesProj/jni/mozjpeg/jpegyuv.c:102

  jpeg_read_header(&cinfo, TRUE);

  cinfo.raw_data_out = TRUE;
  cinfo.do_fancy_upsampling = FALSE;

  jpeg_start_decompress(&cinfo);

  luma_width = cinfo.output_width;
  luma_height = cinfo.output_height;

  chroma_width = (luma_width + 1) >> 1;
  chroma_height = (luma_height + 1) >> 1;

  yuv_size = luma_width*luma_height + 2*chroma_width*chroma_height;
  yuv_buffer = malloc(yuv_size);
  if (!yuv_buffer) {
    fclose(jpg_fd);
    fprintf(stderr, "Memory allocation failure!\n");
    return 1;
  }

  frame_width = (cinfo.output_width + (16 - 1)) & ~(16 - 1);

  jpg_buffer = malloc(frame_width*16 + 2*(frame_width/2)*8);
  if (!jpg_buffer) {
    fclose(jpg_fd);
    free(yuv_buffer);
    fprintf(stderr, "Memory allocation failure!\n");
    return 1;
  }

  plane_pointer[0] = yrow_pointer;
  plane_pointer[1] = cbrow_pointer;
  plane_pointer[2] = crrow_pointer;

  for (y = 0; y < 16; y++) {

View on GitHub (pinned to 45ab8f4308)

Solutions

  1. Downscale the image before converting to YUV, or process in tiles
  2. Check image dimensions before calling jpegyuv and reject images larger than a threshold
  3. Free other memory in the calling process before invoking jpegyuv
  4. Fix the integer overflow: use size_t or int64_t for yuv_size and dimension calculations

Example fix

// before
// no dimension check, potential int overflow in yuv_size

// after
// validate dimensions before calling
if (width > 8192 || height > 8192) {
    fprintf(stderr, "Image too large for YUV conversion: %dx%d\n", width, height);
    return -1;
}
// also fix yuv_size type in jpegyuv.c:
// size_t yuv_size = (size_t)luma_width*(size_t)luma_height
//   + 2*(size_t)chroma_width*(size_t)chroma_height;
Defensive patterns

Strategy: validation

Validate before calling

// Read JPEG dimensions and validate memory feasibility before calling jpegyuv
#include "jpeglib.h"
int validate_jpeg_dimensions(const char *path, int max_dim) {
    struct jpeg_decompress_struct cinfo;
    struct jpeg_error_mgr jerr;
    cinfo.err = jpeg_std_error(&jerr);
    jpeg_create_decompress(&cinfo);
    FILE *f = fopen(path, "rb");
    if (!f) { jpeg_destroy_decompress(&cinfo); return -1; }
    jpeg_stdio_src(&cinfo, f);
    jpeg_read_header(&cinfo, TRUE);
    int w = cinfo.image_width, h = cinfo.image_height;
    fclose(f); jpeg_destroy_decompress(&cinfo);
    if (w <= 0 || h <= 0 || w > max_dim || h > max_dim) return -1;
    // Check yuv_size won't overflow int: w*h + 2*(w/2)*(h/2)
    long yuv = (long)w * h + 2L * (long)((w+1)/2) * (long)((h+1)/2);
    if (yuv > 100*1024*1024) return -1; // cap at 100MB
    return 0;
}

Prevention

When it happens

Trigger: Processing a very high-resolution JPEG (e.g. 10000x10000) where yuv_size exceeds available RAM. Integer overflow in yuv_size calculation producing an unexpected value (the variables are int, so images larger than ~46340x46340 overflow). System under memory pressure.

Common situations: Processing a full-resolution camera photo (e.g. 40MP = ~2400x16000) on a memory-constrained device. Multiple concurrent image conversions. Integer overflow in the multiplication making yuv_size negative or zero, which malloc handles as a tiny allocation (not NULL) or an error.

Related errors


AI-assisted analysis of DrKLO/Telegram@45ab8f4308 (2026-08-14). Data as JSON: /api/errors/175c266a0036cfde. Report an issue: GitHub.