[Bug libstdc++/113258] Pre-C++17 code that replaces malloc/free crashes when mixed with post-C++17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #28 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b255ab901dd0d13ad7f0dc1a823749a5e5f62570 commit r12-10142-gb255ab901dd0d13ad7f0dc1a823749a5e5f62570 Author: Jonathan Wakely Date: Tue Jan 9 15:22:46 2024 + libstdc++: Prefer posix_memalign for aligned-new [PR113258] As described in PR libstdc++/113258 there are old versions of tcmalloc which replace malloc and related APIs, but do not repalce aligned_alloc because it didn't exist at the time they were released. This means that when operator new(size_t, align_val_t) uses aligned_alloc to obtain memory, it comes from libc's aligned_alloc not from tcmalloc. But when operator delete(void*, size_t, align_val_t) uses free to deallocate the memory, that goes to tcmalloc's replacement version of free, which doesn't know how to free it. If we give preference to the older posix_memalign instead of aligned_alloc then we're more likely to use a function that will be compatible with the replacement version of free. Because posix_memalign has been around for longer, it's more likely that old third-party malloc replacements will also replace posix_memalign alongside malloc and free. libstdc++-v3/ChangeLog: PR libstdc++/113258 * libsupc++/new_opa.cc: Prefer to use posix_memalign if available. (cherry picked from commit f50f2efae9fb0965d8ccdb62cfdb698336d5a933)
[Bug libstdc++/113258] Pre-C++17 code that replaces malloc/free crashes when mixed with post-C++17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #27 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c5e12bbb45313df876ee2b81e418851822bed694 commit r13-8307-gc5e12bbb45313df876ee2b81e418851822bed694 Author: Jonathan Wakely Date: Tue Jan 9 15:22:46 2024 + libstdc++: Prefer posix_memalign for aligned-new [PR113258] As described in PR libstdc++/113258 there are old versions of tcmalloc which replace malloc and related APIs, but do not repalce aligned_alloc because it didn't exist at the time they were released. This means that when operator new(size_t, align_val_t) uses aligned_alloc to obtain memory, it comes from libc's aligned_alloc not from tcmalloc. But when operator delete(void*, size_t, align_val_t) uses free to deallocate the memory, that goes to tcmalloc's replacement version of free, which doesn't know how to free it. If we give preference to the older posix_memalign instead of aligned_alloc then we're more likely to use a function that will be compatible with the replacement version of free. Because posix_memalign has been around for longer, it's more likely that old third-party malloc replacements will also replace posix_memalign alongside malloc and free. libstdc++-v3/ChangeLog: PR libstdc++/113258 * libsupc++/new_opa.cc: Prefer to use posix_memalign if available. (cherry picked from commit f50f2efae9fb0965d8ccdb62cfdb698336d5a933)
[Bug libstdc++/113258] Pre-C++17 code that replaces malloc/free crashes when mixed with post-C++17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #26 from Sam James --- Just to close the loop: this ended up being covered originally a few months back with https://airlied.blogspot.com/2023/04/fedora-38-llvm-vs-team-fortress-2-tf2.html and https://gitlab.freedesktop.org/mesa/mesa/-/issues/8133. That's clearly what the original report above is derived from too. Unfortunately, getting fixed copies of libtcmalloc in games which were shipped a decade ago isn't likely. Thanks for the workaround.
[Bug libstdc++/113258] Pre-C++17 code that replaces malloc/free crashes when mixed with post-C++17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #25 from Jonathan Wakely --- Fixed on trunk only so far.
[Bug libstdc++/113258] Pre-C++17 code that replaces malloc/free crashes when mixed with post-C++17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #24 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f50f2efae9fb0965d8ccdb62cfdb698336d5a933 commit r14-7146-gf50f2efae9fb0965d8ccdb62cfdb698336d5a933 Author: Jonathan Wakely Date: Tue Jan 9 15:22:46 2024 + libstdc++: Prefer posix_memalign for aligned-new [PR113258] As described in PR libstdc++/113258 there are old versions of tcmalloc which replace malloc and related APIs, but do not repalce aligned_alloc because it didn't exist at the time they were released. This means that when operator new(size_t, align_val_t) uses aligned_alloc to obtain memory, it comes from libc's aligned_alloc not from tcmalloc. But when operator delete(void*, size_t, align_val_t) uses free to deallocate the memory, that goes to tcmalloc's replacement version of free, which doesn't know how to free it. If we give preference to the older posix_memalign instead of aligned_alloc then we're more likely to use a function that will be compatible with the replacement version of free. Because posix_memalign has been around for longer, it's more likely that old third-party malloc replacements will also replace posix_memalign alongside malloc and free. libstdc++-v3/ChangeLog: PR libstdc++/113258 * libsupc++/new_opa.cc: Prefer to use posix_memalign if available.
[Bug libstdc++/113258] Pre-C++17 code that replaces malloc/free crashes when mixed with post-C++17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Resolution|INVALID |--- Status|RESOLVED|ASSIGNED --- Comment #23 from Jonathan Wakely --- And what matters is not that it's pre-C++17 code that replaces malloc/free, but pre-C11. The C++ standard version being used by the malloc-replacing library is irrelevant, what matters is how dated the malloc replacement is. A C11-aware malloc replacement should also replace aligned_alloc. Anyway, patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642354.html
[Bug libstdc++/113258] Pre-C++17 code that replaces malloc/free crashes when mixed with post-C++17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 Jonathan Wakely changed: What|Removed |Added Summary|Pre-C++17 code that |Pre-C++17 code that |supplies operator |replaces malloc/free |new/delete crashes when |crashes when mixed with |mixed with post-C+17 code |post-C++17 code that uses |that uses the align_val_t |the align_val_t variants of |variants of new/delete |new/delete --- Comment #22 from Jonathan Wakely --- I've fixed the summary, since this is not caused by replacing the old new/delete functions.
