[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