about summary refs log tree commit diff
path: root/malloc
Commit message (Collapse)AuthorAgeFilesLines
* Update copyright dates not handled by scripts/update-copyrightsJoseph Myers2023-01-063-3/+3
| | | | | | I've updated copyright dates in glibc for 2023. This is the patch for the changes not generated by scripts/update-copyrights and subsequent build / regeneration of generated files.
* Update copyright dates with scripts/update-copyrightsJoseph Myers2023-01-0687-87/+87
|
* Avoid use of atoi in mallocJoseph Myers2022-12-221-7/+12
| | | | | | | | | | | | | | | | | | | | | | This patch is analogous to commit a3708cf6b0a5a68e2ed1ce3db28a03ed21d368d2. atoi has undefined behavior on out-of-range input, which makes it problematic to use anywhere in glibc that might be processing input out-of-range for atoi but not specified to produce undefined behavior for the function calling atoi. In conjunction with the C2x strtol changes, use of atoi in libc can also result in localplt test failures because the redirection for strtol does not interact properly with the libc_hidden_proto call for __isoc23_strtol for the call in the inline atoi implementation. In malloc/arena.c, this issue shows up for atoi calls that are only compiled for --disable-tunables (thus with the x86_64-linux-gnu-minimal configuration of build-many-glibcs.py, for example). Change those atoi calls to use strtol directly, as in the previous such changes. Tested for x86_64 (--disable-tunables).
* realloc: Return unchanged if request is within usable sizeSiddhesh Poyarekar2022-12-082-0/+33
| | | | | | | | | | | | | | | | | If there is enough space in the chunk to satisfy the new size, return the old pointer as is, thus avoiding any locks or reallocations. The only real place this has a benefit is in large chunks that tend to get satisfied with mmap, since there is a large enough spare size (up to a page) for it to matter. For allocations on heap, the extra size is typically barely a few bytes (up to 15) and it's unlikely that it would make much difference in performance. Also added a smoke test to ensure that the old pointer is returned unchanged if the new size to realloc is within usable size of the old pointer. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com>
* malloc: Use uintptr_t for pointer alignmentCarlos Eduardo Seo2022-11-011-3/+3
| | | | | | Avoid integer casts that assume unsigned long can represent pointers. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Remove unused scratch_buffer_dupfreeSzabolcs Nagy2022-10-284-63/+0
| | | | | | | | | | | | Turns out scratch_buffer_dupfree internal API was unused since commit ef0700004bf0dccf493a5e8e21f71d9e7972ea9f stdlib: Simplify buffer management in canonicalize And the related test in malloc/tst-scratch_buffer had issues so it's better to remove it completely. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* malloc: Use uintptr_t in alloc_bufferSzabolcs Nagy2022-10-281-3/+3
| | | | | | | The values represnt pointers and not sizes. The members of struct alloc_buffer are already uintptr_t. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* malloc: Switch global_max_fast to uint8_tFlorian Weimer2022-10-131-1/+1
| | | | | | | | MAX_FAST_SIZE is 160 at most, so a uint8_t is sufficient. This makes it harder to use memory corruption, by overwriting global_max_fast with a large value, to fundamentally alter malloc behavior. Reviewed-by: DJ Delorie <dj@redhat.com>
* Use atomic_exchange_release/acquireWilco Dijkstra2022-09-261-1/+1
| | | | | | | Rename atomic_exchange_rel/acq to use atomic_exchange_release/acquire since these map to the standard C11 atomic builtins. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* malloc: Print error when oldsize is not equal to the current size.Qingqing Li2022-09-221-1/+2
| | | | | | | | This is used to detect errors early. The read of the oldsize is not protected by any lock, so check this value to avoid causing bigger mistakes. Reviewed-by: DJ Delorie <dj@redhat.com>
* Use C11 atomics instead of atomic_decrement(_val)Wilco Dijkstra2022-09-091-1/+1
| | | | | | | Replace atomic_decrement and atomic_decrement_val with atomic_fetch_add_relaxed. Reviewed-by: DJ Delorie <dj@redhat.com>
* Use C11 atomics instead atomic_add(_zero)Wilco Dijkstra2022-09-091-1/+1
| | | | | | Replace atomic_add and atomic_add_zero with atomic_fetch_add_relaxed. Reviewed-by: DJ Delorie <dj@redhat.com>
* malloc: Use C11 atomics rather than atomic_exchange_and_addWilco Dijkstra2022-09-061-3/+3
| | | | | | | Replace a few counters using atomic_exchange_and_add with atomic_fetch_add_relaxed. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* malloc: Do not use MAP_NORESERVE to allocate heap segmentsFlorian Weimer2022-08-152-8/+1
| | | | | | | | | | | | | | | | | | Address space for heap segments is reserved in a mmap call with MAP_ANONYMOUS | MAP_PRIVATE and protection flags PROT_NONE. This reservation does not count against the RSS limit of the process or system. Backing memory is allocated using mprotect in alloc_new_heap and grow_heap, and at this point, the allocator expects the kernel to provide memory (subject to memory overcommit). The SIGSEGV that might generate due to MAP_NORESERVE (according to the mmap manual page) does not seem to occur in practice, it's always SIGKILL from the OOM killer. Even if there is a way that SIGSEGV could be generated, it is confusing to applications that this only happens for secondary heaps, not for large mmap-based allocations, and not for the main arena. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* assert: Do not use stderr in libc-internal assertFlorian Weimer2022-08-031-16/+0
| | | | | | | | | | | | | | | | | | | | Redirect internal assertion failures to __libc_assert_fail, based on based on __libc_message, which writes directly to STDERR_FILENO and calls abort. Also disable message translation and reword the error message slightly (adjusting stdlib/tst-bz20544 accordingly). As a result of these changes, malloc no longer needs its own redefinition of __assert_fail. __libc_assert_fail needs to be stubbed out during rtld dependency analysis because the rtld rebuilds turn __libc_assert_fail into __assert_fail, which is unconditionally provided by elf/dl-minimal.c. This change is not possible for the public assert macro and its __assert_fail function because POSIX requires that the diagnostic is written to stderr. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio: Clean up __libc_message after unconditional abortFlorian Weimer2022-08-031-3/+2
| | | | | | | | | | | | Since commit ec2c1fcefb200c6cb7e09553f3c6af8815013d83 ("malloc: Abort on heap corruption, without a backtrace [BZ #21754]"), __libc_message always terminates the process. Since commit a289ea09ea843ced6e5277c2f2e63c357bc7f9a3 ("Do not print backtraces on fatal glibc errors"), the backtrace facility has been removed. Therefore, remove enum __libc_message_action and the action argument of __libc_message, and mark __libc_message as _No_return. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* malloc: Use __getrandom_nocancel during tcache initiailizationFlorian Weimer2022-08-011-1/+2
| | | | | | | | | | Cancellation currently cannot happen at this point because dlopen as used by the unwind link always performs additional allocations for libgcc_s.so.1, even if it has been loaded already as a dependency of the main executable. But it seems prudent not to rely on this quirk. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Remove spurious references to _dl_open_hookFlorian Weimer2022-08-011-5/+0
| | | | | | | _dl_open_hook was removed in commit 466c1ea15f461edb8e3ffaf5d86d708 ("dlfcn: Rework static dlopen hooks"). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdlib: Add arc4random, arc4random_buf, and arc4random_uniform (BZ #4417)Adhemerval Zanella Netto2022-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The implementation is based on scalar Chacha20 with per-thread cache. It uses getrandom or /dev/urandom as fallback to get the initial entropy, and reseeds the internal state on every 16MB of consumed buffer. To improve performance and lower memory consumption the per-thread cache is allocated lazily on first arc4random functions call, and if the memory allocation fails getentropy or /dev/urandom is used as fallback. The cache is also cleared on thread exit iff it was initialized (so if arc4random is not called it is not touched). Although it is lock-free, arc4random is still not async-signal-safe (the per thread state is not updated atomically). The ChaCha20 implementation is based on RFC8439 [1], omitting the final XOR of the keystream with the plaintext because the plaintext is a stream of zeros. This strategy is similar to what OpenBSD arc4random does. The arc4random_uniform is based on previous work by Florian Weimer, where the algorithm is based on Jérémie Lumbroso paper Optimal Discrete Uniform Generation from Coin Flips, and Applications (2013) [2], who credits Donald E. Knuth and Andrew C. Yao, The complexity of nonuniform random number generation (1976), for solving the general case. The main advantage of this method is the that the unit of randomness is not the uniform random variable (uint32_t), but a random bit. It optimizes the internal buffer sampling by initially consuming a 32-bit random variable and then sampling byte per byte. Depending of the upper bound requested, it might lead to better CPU utilization. Checked on x86_64-linux-gnu, aarch64-linux, and powerpc64le-linux-gnu. Co-authored-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Yann Droneaud <ydroneaud@opteya.com> [1] https://datatracker.ietf.org/doc/html/rfc8439 [2] https://arxiv.org/pdf/1304.1916.pdf
* malloc: Simplify implementation of __malloc_assertFlorian Weimer2022-07-211-10/+5
| | | | | | | | | | It is prudent not to run too much code after detecting heap corruption, and __fxprintf is really complex. The line number and file name do not carry much information, so it is not included in the error message. (__libc_message only supports %s formatting.) The function name and assertion should provide some context. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* malloc: Simplify checked_request2size interfaceFlorian Weimer2022-07-052-15/+18
| | | | | | | In-band signaling avoids an uninitialized variable warning when building with -Og and GCC 12. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* malloc: Fix duplicate inline for do_set_mxfastAdhemerval Zanella2022-03-231-2/+1
|
* malloc: Exit early on test failure in tst-reallocFlorian Weimer2022-03-101-31/+15
| | | | | | | | | | This addresses more (correct) use-after-free warnings reported by GCC 12 on some targets. Fixes commit c094c232eb3246154265bb035182f92fe1b17ab8 ("Avoid -Wuse-after-free in tests [BZ #26779]."). Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* build: Properly generate .d dependency files [BZ #28922]H.J. Lu2022-02-251-1/+1
| | | | | | | | | | | | | 1. Also generate .d dependency files for $(tests-container) and $(tests-printers). 2. elf: Add tst-auditmod17.os to extra-test-objs. 3. iconv: Add tst-gconv-init-failure-mod.os to extra-test-objs. 4. malloc: Rename extra-tests-objs to extra-test-objs. 5. linux: Add tst-sysconf-iov_max-uapi.o to extra-test-objs. 6. x86_64: Add tst-x86_64mod-1.o, tst-platformmod-2.o, test-libmvec.o, test-libmvec-avx.o, test-libmvec-avx2.o and test-libmvec-avx512f.o to extra-test-objs. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* malloc: Remove LD_TRACE_PRELINKING usage from mtraceAdhemerval Zanella2022-02-101-24/+31
| | | | | | | | | | | | | | | | | | | | | | The fix for BZ#22716 replacde LD_TRACE_LOADED_OBJECTS with LD_TRACE_PRELINKING so mtrace could record executable address position. To provide the same information, LD_TRACE_LOADED_OBJECTS is extended where a value or '2' also prints the executable address as well. It avoid adding another loader environment variable to be used solely for mtrace. The vDSO will be printed as a default library (with '=>' pointing the same name), which is ok since both mtrace and ldd already handles it. The mtrace script is changed to also parse the new format. To correctly support PIE and non-PIE executables, both the default mtrace address and the one calculated as used (it fixes mtrace for non-PIE exectuable as for BZ#22716 for PIE). Checked on x86_64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* malloc: Fix tst-mallocalign1 macro spacing.Carlos O'Donell2022-02-011-1/+1
| | | | Reported by Andreas Schwab <schwab@linux-m68k.org>
* malloc: Fix -Wuse-after-free warning in tst-mallocalign1 [BZ #26779]Carlos O'Donell2022-01-311-9/+11
| | | | | | | | | | | | | | The test leaks bits from the freed pointer via the return value in ret, and the compiler correctly identifies this issue. We switch the test to use TEST_VERIFY and terminate the test if any of the pointers return an unexpected alignment. This fixes another -Wuse-after-free error when compiling glibc with gcc 12. Tested on x86_64 and i686 without regression. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Avoid -Wuse-after-free in tests [BZ #26779].Martin Sebor2022-01-265-1/+58
| | | | Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Update copyright dates not handled by scripts/update-copyrights.Paul Eggert2022-01-013-3/+3
| | | | | | | | | | | | | | I've updated copyright dates in glibc for 2022. This is the patch for the changes not generated by scripts/update-copyrights and subsequent build / regeneration of generated files. As well as the usual annual updates, mainly dates in --version output (minus csu/version.c which previously had to be handled manually but is now successfully updated by update-copyrights), there is a small change to the copyright notice in NEWS which should let NEWS get updated automatically next year. Please remember to include 2022 in the dates for any new files added in future (which means updating any existing uncommitted patches you have that add new files to use the new copyright dates in them).
* Update copyright dates with scripts/update-copyrightsPaul Eggert2022-01-0188-88/+88
| | | | | | | | | | | | | | | | | | | | | | | I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 7061 files FOO. I then removed trailing white space from math/tgmath.h, support/tst-support-open-dev-null-range.c, and sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following obscure pre-commit check failure diagnostics from Savannah. I don't know why I run into these diagnostics whereas others evidently do not. remote: *** 912-#endif remote: *** 913: remote: *** 914- remote: *** error: lines with trailing whitespace found ... remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines
* malloc: Remove memusage.hAdhemerval Zanella2021-12-281-6/+7
| | | | | | And use machine-sp.h instead. The Linux implementation is based on already provided CURRENT_STACK_FRAME (used on nptl code) and STACK_GROWS_UPWARD is replaced with _STACK_GROWS_UP.
* malloc: Use hp-timing on libmemusageAdhemerval Zanella2021-12-281-3/+21
| | | | Instead of reimplemeting on GETTIME macro.
* malloc: Remove atomic_* usageAdhemerval Zanella2021-12-281-18/+18
| | | | | These typedef are used solely on memusage and can be replaced with generic types.
* malloc: Add missing shared thread library flagsSamuel Thibault2021-12-271-0/+16
|
* Remove upper limit on tunable MALLOC_MMAP_THRESHOLDPatrick McGehearty2021-12-161-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The current limit on MALLOC_MMAP_THRESHOLD is either 1 Mbyte (for 32-bit apps) or 32 Mbytes (for 64-bit apps). This value was set by a patch dated 2006 (15 years ago). Attempts to set the threshold higher are currently ignored. The default behavior is appropriate for many highly parallel applications where many processes or threads are sharing RAM. In other situations where the number of active processes or threads closely matches the number of cores, a much higher limit may be desired by the application designer. By today's standards on personal computers and small servers, 2 Gbytes of RAM per core is commonly available. On larger systems 4 Gbytes or more of RAM is sometimes available. Instead of raising the limit to match current needs, this patch proposes to remove the limit of the tunable, leaving the decision up to the user of a tunable to judge the best value for their needs. This patch does not change any of the defaults for malloc tunables, retaining the current behavior of the dynamic malloc mmap threshold. bugzilla 27801 - Remove upper limit on tunable MALLOC_MMAP_THRESHOLD Reviewed-by: DJ Delorie <dj@redhat.com> malloc/ malloc.c changed do_set_mmap_threshold to remove test for HEAP_MAX_SIZE.
* malloc: Enable huge page support on main arenaAdhemerval Zanella2021-12-153-6/+14
| | | | | | | | | | | | This patch adds support huge page support on main arena allocation, enable with tunable glibc.malloc.hugetlb=2. The patch essentially disable the __glibc_morecore() sbrk() call (similar when memory tag does when sbrk() call does not support it) and fallback to default page size if the memory allocation fails. Checked on x86_64-linux-gnu. Reviewed-by: DJ Delorie <dj@redhat.com>
* malloc: Move MORECORE fallback mmap to sysmalloc_mmap_fallbackAdhemerval Zanella2021-12-151-32/+53
| | | | | | So it can be used on hugepage code as well. Reviewed-by: DJ Delorie <dj@redhat.com>
* malloc: Add Huge Page support to arenasAdhemerval Zanella2021-12-153-44/+99
| | | | | | | | | | | | | | | | | | | | | | | It is enabled as default for glibc.malloc.hugetlb set to 2 or higher. It also uses a non configurable minimum value and maximum value, currently set respectively to 1 and 4 selected huge page size. The arena allocation with huge pages does not use MAP_NORESERVE. As indicate by kernel internal documentation [1], the flag might trigger a SIGBUS on soft page faults if at memory access there is no left pages in the pool. On systems without a reserved huge pages pool, is just stress the mmap(MAP_HUGETLB) allocation failure. To improve test coverage it is required to create a pool with some allocated pages. Checked on x86_64-linux-gnu with no reserved pages, 10 reserved pages (which trigger mmap(MAP_HUGETBL) failures) and with 256 reserved pages (which does not trigger mmap(MAP_HUGETLB) failures). [1] https://www.kernel.org/doc/html/v4.18/vm/hugetlbfs_reserv.html#resv-map-modifications Reviewed-by: DJ Delorie <dj@redhat.com>
* malloc: Add Huge Page support for mmapAdhemerval Zanella2021-12-153-9/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | With the morecore hook removed, there is not easy way to provide huge pages support on with glibc allocator without resorting to transparent huge pages. And some users and programs do prefer to use the huge pages directly instead of THP for multiple reasons: no splitting, re-merging by the VM, no TLB shootdowns for running processes, fast allocation from the reserve pool, no competition with the rest of the processes unlike THP, no swapping all, etc. This patch extends the 'glibc.malloc.hugetlb' tunable: the value '2' means to use huge pages directly with the system default size, while a positive value means and specific page size that is matched against the supported ones by the system. Currently only memory allocated on sysmalloc() is handled, the arenas still uses the default system page size. To test is a new rule is added tests-malloc-hugetlb2, which run the addes tests with the required GLIBC_TUNABLE setting. On systems without a reserved huge pages pool, is just stress the mmap(MAP_HUGETLB) allocation failure. To improve test coverage it is required to create a pool with some allocated pages. Checked on x86_64-linux-gnu. Reviewed-by: DJ Delorie <dj@redhat.com>
* malloc: Move mmap logic to its own functionAdhemerval Zanella2021-12-151-76/+88
| | | | | | So it can be used with different pagesize and flags. Reviewed-by: DJ Delorie <dj@redhat.com>
* malloc: Add THP/madvise support for sbrkAdhemerval Zanella2021-12-151-5/+29
| | | | | | | | | | To increase effectiveness with Transparent Huge Page with madvise, the large page size is use instead page size for sbrk increment for the main arena. Checked on x86_64-linux-gnu. Reviewed-by: DJ Delorie <dj@redhat.com>
* malloc: Add madvise support for Transparent Huge PagesAdhemerval Zanella2021-12-154-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | Linux Transparent Huge Pages (THP) current supports three different states: 'never', 'madvise', and 'always'. The 'never' is self-explanatory and 'always' will enable THP for all anonymous pages. However, 'madvise' is still the default for some system and for such case THP will be only used if the memory range is explicity advertise by the program through a madvise(MADV_HUGEPAGE) call. To enable it a new tunable is provided, 'glibc.malloc.hugetlb', where setting to a value diffent than 0 enables the madvise call. This patch issues the madvise(MADV_HUGEPAGE) call after a successful mmap() call at sysmalloc() with sizes larger than the default huge page size. The madvise() call is disable is system does not support THP or if it has the mode set to "never" and on Linux only support one page size for THP, even if the architecture supports multiple sizes. To test is a new rule is added tests-malloc-hugetlb1, which run the addes tests with the required GLIBC_TUNABLE setting. Checked on x86_64-linux-gnu. Reviewed-by: DJ Delorie <dj@redhat.com>
* malloc: Fix malloc debug for 2.35 onwardsStafford Horne2021-11-171-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change 1e5a5866cb ("Remove malloc hooks [BZ #23328]") has broken ports that are using GLIBC_2_35, like the new OpenRISC port I am working on. The libc_malloc_debug.so library used to bring in the debug infrastructure is currently essentially empty for GLIBC_2_35 ports like mine causing mtrace tests to fail: cat sysdeps/unix/sysv/linux/or1k/shlib-versions DEFAULT GLIBC_2.35 ld=ld-linux-or1k.so.1 FAIL: posix/bug-glob2-mem FAIL: posix/bug-regex14-mem FAIL: posix/bug-regex2-mem FAIL: posix/bug-regex21-mem FAIL: posix/bug-regex31-mem FAIL: posix/bug-regex36-mem FAIL: malloc/tst-mtrace. The issue seems to be with the ifdefs in malloc/malloc-debug.c. The ifdefs are currently essentially exluding all symbols for ports > 2.35. Removing the top level SHLIB_COMPAT ifdef allows things to just work. Fixes: 1e5a5866cb ("Remove malloc hooks [BZ #23328]") Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* elf: Introduce GLRO (dl_libc_freeres), called from __libc_freeresFlorian Weimer2021-11-171-0/+5
| | | | | | | This will be used to deallocate memory allocated using the non-minimal malloc. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Disable -Waggressive-loop-optimizations warnings in tst-dynarray.cJoseph Myers2021-10-291-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My build-many-glibcs.py bot shows -Waggressive-loop-optimizations errors building the glibc testsuite for 32-bit architectures with GCC mainline, which seem to have appeared between GCC commits 4abc0c196b10251dc80d0743ba9e8ab3e56c61ed and d8edfadfc7a9795b65177a50ce44fd348858e844: In function 'dynarray_long_noscratch_resize', inlined from 'test_long_overflow' at tst-dynarray.c:489:5, inlined from 'do_test' at tst-dynarray.c:571:3: ../malloc/dynarray-skeleton.c:391:36: error: iteration 1073741823 invokes undefined behavior [-Werror=aggressive-loop-optimizations] 391 | DYNARRAY_ELEMENT_INIT (&list->u.dynarray_header.array[i]); tst-dynarray.c:39:37: note: in definition of macro 'DYNARRAY_ELEMENT_INIT' 39 | #define DYNARRAY_ELEMENT_INIT(e) (*(e) = 23) | ^ In file included from tst-dynarray.c:42: ../malloc/dynarray-skeleton.c:389:37: note: within this loop 389 | for (size_t i = old_size; i < size; ++i) | ~~^~~~~~ In function 'dynarray_long_resize', inlined from 'test_long_overflow' at tst-dynarray.c:479:5, inlined from 'do_test' at tst-dynarray.c:571:3: ../malloc/dynarray-skeleton.c:391:36: error: iteration 1073741823 invokes undefined behavior [-Werror=aggressive-loop-optimizations] 391 | DYNARRAY_ELEMENT_INIT (&list->u.dynarray_header.array[i]); tst-dynarray.c:27:37: note: in definition of macro 'DYNARRAY_ELEMENT_INIT' 27 | #define DYNARRAY_ELEMENT_INIT(e) (*(e) = 17) | ^ In file included from tst-dynarray.c:28: ../malloc/dynarray-skeleton.c:389:37: note: within this loop 389 | for (size_t i = old_size; i < size; ++i) | ~~^~~~~~ I don't know what GCC change made these errors appear, or why they only appear for 32-bit architectures. However, the warnings appear to be both true (that iteration would indeed involve undefined behavior if executed) and useless in this particular case (that iteration is never executed, because the allocation size overflows and so the allocation fails - but the check for allocation size overflow is in a separate source file and so can't be seen by the compiler when compiling this test). So use the DIAG_* macros to disable -Waggressive-loop-optimizations around the calls in question to dynarray_long_resize and dynarray_long_noscratch_resize in this test. Tested with build-many-glibcs.py (GCC mainline) for arm-linux-gnueabi, where it restores a clean testsuite build.
* Handle NULL input to malloc_usable_size [BZ #28506]Siddhesh Poyarekar2021-10-293-35/+25
| | | | | | | | | | Hoist the NULL check for malloc_usable_size into its entry points in malloc-debug and malloc and assume non-NULL in all callees. This fixes BZ #28506 Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
* Add alloc_align attribute to memalign et alJonathan Wakely2021-10-211-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC 4.9.0 added the alloc_align attribute to say that a function argument specifies the alignment of the returned pointer. Clang supports the attribute too. Using the attribute can allow a compiler to generate better code if it knows the returned pointer has a minimum alignment. See https://gcc.gnu.org/PR60092 for more details. GCC implicitly knows the semantics of aligned_alloc and posix_memalign, but not the obsolete memalign. As a result, GCC generates worse code when memalign is used, compared to aligned_alloc. Clang knows about aligned_alloc and memalign, but not posix_memalign. This change adds a new __attribute_alloc_align__ macro to <sys/cdefs.h> and then uses it on memalign (where it helps GCC) and aligned_alloc (where GCC and Clang already know the semantics, but it doesn't hurt) and xposix_memalign. It can't be used on posix_memalign because that doesn't return a pointer (the allocated pointer is returned via a void** parameter instead). Unlike the alloc_size attribute, alloc_align only allows a single argument. That means the new __attribute_alloc_align__ macro doesn't really need to be used with double parentheses to protect a comma between its arguments. For consistency with __attribute_alloc_size__ this patch defines it the same way, so that double parentheses are required. Signed-off-by: Jonathan Wakely <jwakely@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* misc: Add __get_nprocs_schedAdhemerval Zanella2021-09-271-1/+1
| | | | | | | | | | | This is an internal function meant to return the number of avaliable processor where the process can scheduled, different than the __get_nprocs which returns a the system available online CPU. The Linux implementation currently only calls __get_nprocs(), which in tuns calls sched_getaffinity. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Remove "Contributed by" linesSiddhesh Poyarekar2021-09-0317-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | We stopped adding "Contributed by" or similar lines in sources in 2012 in favour of git logs and keeping the Contributors section of the glibc manual up to date. Removing these lines makes the license header a bit more consistent across files and also removes the possibility of error in attribution when license blocks or files are copied across since the contributed-by lines don't actually reflect reality in those cases. Move all "Contributed by" and similar lines (Written by, Test by, etc.) into a new file CONTRIBUTED-BY to retain record of these contributions. These contributors are also mentioned in manual/contrib.texi, so we just maintain this additional record as a courtesy to the earlier developers. The following scripts were used to filter a list of files to edit in place and to clean up the CONTRIBUTED-BY file respectively. These were not added to the glibc sources because they're not expected to be of any use in future given that this is a one time task: https://gist.github.com/siddhesh/b5ecac94eabfd72ed2916d6d8157e7dc https://gist.github.com/siddhesh/15ea1f5e435ace9774f485030695ee02 Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* mtrace: Fix output with PIE and ASLR [BZ #22716]Siddhesh Poyarekar2021-08-232-11/+10
| | | | | | | | | | | | | | Record only the relative address of the caller in mtrace file. Use LD_TRACE_PRELINKING to get the executable as well as binary vs executable load offsets so that we may compute a base to add to the relative address in the mtrace file. This allows us to get a valid address to pass to addr2line in all cases. Fixes BZ #22716. Co-authored-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: Andreas Schwab <schwab@linux-m68k.org> Reviewed-by: DJ Delorie <dj@redhat.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-03 08:21:11 +0000