What causes "cimg::fclose(): Specified file is (null)." in Yalantis/uCrop?

Check the FILE* for null before calling cimg::fclose, and only close handles that are non-null.

cimg::fclose(): Specified file is (null).

Error message

cimg::fclose(): Specified file is (null).

What it means

Warning from CImg's cimg::fclose(std::FILE*) helper, a wrapper over std::fclose() that reports problems instead of failing silently. If the passed FILE* is null, it warns "Specified file is (null)" and returns 0 without attempting any close. This indicates a bookkeeping bug in the caller: code saved/propagated a null FILE* and still tried to close it.

Source

Thrown at ucrop/src/main/jni/CImg.h:7581

          if (_setmode(_fileno(res),0x8000)==-1) res = 0;
#endif
        }
#endif
      } else res = cimg::std_fopen(path,mode);
      if (!res) throw CImgIOException("cimg::fopen(): Failed to open file '%s' with mode '%s'.",
                                      path,mode);
      return res;
    }

    //! Close a file.
    /**
       \param file File to close.
       \return \c 0 if file has been closed properly, something else otherwise.
       \note Same as <tt>std::fclose()</tt> but display a warning message if
       the file has not been closed properly.
    **/
    inline int fclose(std::FILE *file) {
      if (!file) { warn("cimg::fclose(): Specified file is (null)."); return 0; }
      if (file==cimg::_stdin(false) || file==cimg::_stdout(false)) return 0;
      const int errn = std::fclose(file);
      if (errn!=0) warn("cimg::fclose(): Error code %d returned during file closing.",
                        errn);
      return errn;
    }

    //! Version of 'fseek()' that supports >=64bits offsets everywhere (for Windows).
    inline int fseek(FILE *stream, cimg_long offset, int origin) {
#if defined(WIN64) || defined(_WIN64) || defined(__WIN64__)
      return _fseeki64(stream,(__int64)offset,origin);
#else
      return std::fseek(stream,offset,origin);
#endif
    }

    //! Version of 'ftell()' that supports >=64bits offsets everywhere (for Windows).
    inline cimg_long ftell(FILE *stream) {

View on GitHub (pinned to f788b534b4)

Solutions

Check the FILE* for null before calling cimg::fclose, and only close handles that are non-null.
Check the return value of cimg::fopen/std::fopen immediately and handle failure before proceeding to use or close the file.
Restructure cleanup so the close only runs when the file was actually opened (single ownership of the handle).
If this fires inside library code, verify the filename passed to the load/save call exists and is readable so fopen succeeds.
Silence-check logging: since it returns 0, callers that treat the result as success will pass — audit call sites rather than the return value.

Example fix

// before
std::FILE *f = cimg::fopen(path,"r");
process(f);
cimg::fclose(f); // warns if fopen failed
// after
std::FILE *f = cimg::fopen(path,"r");
if (f) { process(f); cimg::fclose(f); }
else cimg::warn("Could not open %s", path);

Defensive patterns

Strategy: type-guard

Validate before calling

std::FILE *f = cimg::fopen(path, "r");
if (!f) { /* handle open failure: report path, errno */ }

Type guard

bool is_open(std::FILE *f) { return f != nullptr; }
// usage: if (is_open(f)) cimg::fclose(f);

Try / catch

// C API style: guard the handle before closing
if (file) {
  cimg::fclose(file);
  file = nullptr; // prevent double close
} else {
  // handle/report the never-opened case
}

Prevention

Always check the FILE* returned by fopen/cimg::fopen before any use or close.
Null the pointer after closing so cleanup cannot double-close or close null.
Structure code so fclose runs only when the corresponding fopen succeeded (RAII wrapper or single-exit guard).
Investigate any 'Specified file is (null)' warning as a caller bug, not a library fault: trace why the handle was null.

When it happens

Trigger: Calling cimg::fclose(NULL), or fclose on a FILE* variable that was never assigned because the preceding cimg::fopen/std::fopen failed and its null return was not checked; also happens when a load/save path kept a null handle from a skipped branch.

Common situations: Unchecked fopen failure (bad path, missing file, no permissions) followed by cleanup code that unconditionally calls cimg::fclose; double-close logic where the first close nulled the pointer but a second path still calls with a stale null; conditional resource handling in custom I/O code built on CImg's file helpers.

Related errors

AI-assisted analysis of Yalantis/uCrop@f788b534b4 (2026-09-08). Data as JSON: /api/errors/accb094458a7eb22. Report an issue: GitHub.