glibc/libio/genops.c, branch vdso

libio: Attempt wide backup free only for non-legacy code

2024-09-04T13:29:35Z

_wide_data and _mode are not available in legacy code, so do not attempt to free the wide backup buffer in legacy code. Resolves: BZ #32137 and BZ #27821 Signed-off-by: Siddhesh Poyarekar Reviewed-by: Florian Weimer

ungetc: Fix backup buffer leak on program exit [BZ #27821]

2024-08-15T17:56:13Z

If a file descriptor is left unclosed and is cleaned up by _IO_cleanup on exit, its backup buffer remains unfreed, registering as a leak in valgrind. This is not strictly an issue since (1) the program should ideally be closing the stream once it's not in use and (2) the program is about to exit anyway, so keeping the backup buffer around a wee bit longer isn't a real problem. Free it anyway to keep valgrind happy when the streams in question are the standard ones, i.e. stdout, stdin or stderr. Also, the _IO_have_backup macro checks for _IO_save_base, which is a roundabout way to check for a backup buffer instead of directly looking for _IO_backup_base. The roundabout check breaks when the main get area has not been used and user pushes a char into the backup buffer with ungetc. Fix this to use the _IO_backup_base directly. Signed-off-by: Siddhesh Poyarekar Reviewed-by: Carlos O'Donell

ungetc: Fix uninitialized read when putting into unused streams [BZ #27821]

2024-08-15T17:55:07Z

When ungetc is called on an unused stream, the backup buffer is allocated without the main get area being present. This results in every subsequent ungetc (as the stream remains in the backup area) checking uninitialized memory in the backup buffer when trying to put a character back into the stream. Avoid comparing the input character with buffer contents when in backup to avoid this uninitialized read. The uninitialized read is harmless in this context since the location is promptly overwritten with the input character, thus fulfilling ungetc functionality. Also adjust wording in the manual to drop the paragraph that says glibc cannot do multiple ungetc back to back since with this change, ungetc can actually do this. Signed-off-by: Siddhesh Poyarekar Reviewed-by: Carlos O'Donell

libio: handle opening a file when all files are closed (bug 31963)

2024-07-09T08:12:36Z

_IO_list_all becomes NULL when all files (including standard files) are closed.

Use a doubly-linked list for _IO_list_all (bug 27777)

2024-05-17T21:13:25Z

This patch fixes BZ #27777 "fclose does a linear search, takes ages when many FILE* are opened". Simply put, the master list of opened (FILE*), namely _IO_list_all, is a singly-linked list. As a consequence, the removal of a single element is in O(N), which cripples the performance of fclose(). The patch switches to a doubly-linked list, yielding O(1) removal. The one padding field in struct _IO_FILE, __pad5, is renamed to _prevchain for a doubly-linked list. Since fields in struct _IO_FILE after the _lock field are internal to glibc and opaque to applications. We can change them as long as the size of struct _IO_FILE is unchanged, which is checked as the part of glibc ABI with sizes of _IO_2_1_stdin_, _IO_2_1_stdout_ and _IO_2_1_stderr_. NB: When _IO_vtable_offset (fp) == 0, copy relocation will cover the whole struct _IO_FILE. Otherwise, only fields up to the _lock field will be copied to applications at run-time. It is used to check if the _prevchain field can be safely accessed. After opening 2 million (FILE*), the fclose() of 100 of them takes quite a few seconds without the patch, and under 2 seconds with it on a loaded machine. No test is added since there are no functional changes. Co-Authored-By: H.J. Lu Signed-off-by: Alexandre Ferrieux Signed-off-by: H.J. Lu Reviewed-by: Carlos O'Donell

Update copyright dates with scripts/update-copyrights

2024-01-01T18:53:40Z

Always do locking when accessing streams (bug 15142, bug 14697)

2023-07-03T07:55:43Z

Now that abort no longer calls fflush there is no reason to avoid locking the stdio streams anywhere. This fixes a conformance issue and potential heap corruption during exit.

Move libc_freeres_ptrs and libc_subfreeres to hidden/weak functions

2023-03-27T16:57:55Z

They are both used by __libc_freeres to free all library malloc allocated resources to help tooling like mtrace or valgrind with memory leak tracking. The current scheme uses assembly markers and linker script entries to consolidate the free routine function pointers in the RELRO segment and to be freed buffers in BSS. This patch changes it to use specific free functions for libc_freeres_ptrs buffers and call the function pointer array directly with call_function_static_weak. It allows the removal of both the internal macros and the linker script sections. Checked on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Carlos O'Donell

Update copyright dates with scripts/update-copyrights

2023-01-06T21:14:39Z

stdlib: Move _IO_cleanup to call_function_static_weak

2022-12-12T12:53:23Z

Reviewed-by: Florian Weimer