What causes "%s: can't allocate memory for ICC profile " in DrKLO/Telegram?

Free memory before encoding or reduce concurrency; raise the process memory ulimit if appropriate.

%s: can't allocate memory for ICC profile

Error message

%s: can't allocate memory for ICC profile

What it means

cjpeg allocates a buffer of icc_len bytes with malloc to hold the ICC profile. If malloc returns NULL (insufficient memory, or icc_len was absurdly large due to a corrupt size), it prints this message, closes the file, and exits EXIT_FAILURE.

Source

Thrown at TMessagesProj/jni/mozjpeg/cjpeg.c:774

  } else if (!memdst) {
    /* default output file is stdout */
    output_file = write_stdout();
  }

  if (icc_filename != NULL) {
    if ((icc_file = fopen(icc_filename, READ_BINARY)) == NULL) {
      fprintf(stderr, "%s: can't open %s\n", progname, icc_filename);
      exit(EXIT_FAILURE);
    }
    if (fseek(icc_file, 0, SEEK_END) < 0 ||
        (icc_len = ftell(icc_file)) < 1 ||
        fseek(icc_file, 0, SEEK_SET) < 0) {
      fprintf(stderr, "%s: can't determine size of %s\n", progname,
              icc_filename);
      exit(EXIT_FAILURE);
    }
    if ((icc_profile = (JOCTET *)malloc(icc_len)) == NULL) {
      fprintf(stderr, "%s: can't allocate memory for ICC profile\n", progname);
      fclose(icc_file);
      exit(EXIT_FAILURE);
    }
    if (fread(icc_profile, icc_len, 1, icc_file) < 1) {
      fprintf(stderr, "%s: can't read ICC profile from %s\n", progname,
              icc_filename);
      free(icc_profile);
      fclose(icc_file);
      exit(EXIT_FAILURE);
    }
    fclose(icc_file);
  }

#ifdef PROGRESS_REPORT
  start_progress_monitor((j_common_ptr)&cinfo, &progress);
#endif

  /* Figure out the input file format, and set up to read it. */

View on GitHub (pinned to 45ab8f4308)

Solutions

Free memory before encoding or reduce concurrency; raise the process memory ulimit if appropriate.
Sanity-check the reported ICC size (a real ICC profile is typically a few KB to a few MB) and reject implausibly large files before passing -icc.
Verify the file is actually an ICC profile and not a large unrelated binary.

Example fix

# before: huge/corrupt file exhausts malloc
cjpeg -icc huge.bin in.ppm out.jpg
# after: validate size first
size=$(stat -c%s profile.icc); [ "$size" -lt 1048576 ] && cjpeg -icc profile.icc in.ppm out.jpg

Defensive patterns

Strategy: validation

Validate before calling

#!/bin/sh
ICC="$1"; MAX=$((2*1024*1024))  # ICC profiles are at most a few MB
size=$(stat -c%s "$ICC" 2>/dev/null || stat -f%z "$ICC")
[ "$size" -ge 1 ] 2>/dev/null && [ "$size" -le "$MAX" ] || { echo "ICC size implausible ($size): $ICC" >&2; exit 1; }
cjpeg -icc "$ICC" in.ppm out.jpg

Type guard

// n/a: resource precondition check in the caller.

Try / catch

if ! cjpeg -icc "$ICC" in.ppm out.jpg 2>/tmp/e; then
  grep -q 'allocate memory for ICC' /tmp/e && { echo 'OOM: reduce concurrency or shrink/recheck ICC' >&2; exit 1; }
fi

Prevention

Cap and validate ICC file size before allocation (typical profiles < 1 MB).
Limit concurrent encoding jobs on memory-constrained devices.
Raise ulimit -v / cgroup memory limits if legitimately large profiles are used.

When it happens

Trigger: The system cannot satisfy the malloc(icc_len) request: genuine out-of-memory, a malformed file whose ftell reported an enormous length, or ulimit/cgroup memory caps on the process.

Common situations: Embedded/mobile environments with tight memory limits; a corrupted file causing ftell to report a multi-GB size; many concurrent encodings exhausting RAM; a path resolution bug pointing at a huge unrelated file.

Related errors

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