[Bug stdio/31838] New: There seems to be a memory leak bug in the fdopen function

simonzgx at gmail dot com sourceware-bugzilla@sourceware.org
Mon Jun 3 12:46:55 GMT 2024


https://sourceware.org/bugzilla/show_bug.cgi?id=31838

            Bug ID: 31838
           Summary: There seems to be a memory leak bug in the fdopen
                    function
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: stdio
          Assignee: unassigned at sourceware dot org
          Reporter: simonzgx at gmail dot com
  Target Milestone: ---

As shown in the ``libio/iofdopen.c``

FILE *
_IO_new_fdopen (int fd, const char *mode)
{
  int read_write;
  struct locked_FILE
  {
    struct _IO_FILE_plus fp;
#ifdef _IO_MTSAFE_IO
    _IO_lock_t lock;
#endif
    struct _IO_wide_data wd;
  } *new_f;

  // some code is omitted here
  new_f = (struct locked_FILE *) malloc (sizeof (struct locked_FILE));
  if (new_f == NULL)
    return NULL;
        // some code is omitted here
  if (do_seek && ((read_write & (_IO_IS_APPENDING | _IO_NO_READS))
                  == (_IO_IS_APPENDING | _IO_NO_READS)))
    {
      off64_t new_pos = _IO_SYSSEEK (&new_f->fp.file, 0, _IO_seek_end);
      if (new_pos == _IO_pos_BAD && errno != ESPIPE)
      // should call free(new_f) to release memory here
        return NULL;
    }
  return &new_f->fp.file;
}


When the ``_IO_SYSSEEK`` returns an unexpected value, we forget to call
free(new_f) to free memory.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Glibc-bugs mailing list