| Summary: | memcheck/tests/duplicate_align_size_errors.cpp fails | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Florian Krohm <flo2030> |
| Component: | memcheck | Assignee: | Paul Floyd <pjfloyd> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | pjfloyd |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
stderr diff
duplicate_align_size_errors.objdump |
||
Created attachment 184713 [details]
duplicate_align_size_errors.objdump
I was just looking at this. On older libcs aligned_alloc is just a weak alias for memalign 000000000009c030 T __libc_memalign@@GLIBC_2.2.5 000000000009c030 W aligned_alloc@@GLIBC_2.16 000000000009c030 W memalign@@GLIBC_2.2.5 The man page claims that the alignment value must be a power of two but in fact libc secretly rounds it up to the next power of two and does not complain. Tools that replace malloc on Linux still have this strange behaviour (but with an error message). The man page also says that aligned_alloc has a further restriction that size must be a multiple of alignemnt. Again due to the alias that was not true. Newer libcs have a separate aligned_alloc that respects the man page. In Valgrind, we redirect both memalign and aligned_alloc, but with a weak alias it is the last one that gets kept. And that is memalign. And now that I look at the error it strikes me as inconsistent. I was probably thinking too much of these alias issues. There are 2 things that I think I should do 1. Change the message to be "Invalid size value : 0 (should be ...)" 2. Add a 'memalign' expected. I don't think that AddressSanitizer does a very good job here either. It doesn't complain about the operator new with an alignment of zero and it performs an allocation (but without ASAN libstdc++ returns a NULL pointer). The ASAN message for the first aligned_alloc (and note that ASAN, with compile time instrumentation, redirects aligned_alloc not memalign) is ==4125927==ERROR: AddressSanitizer: invalid alignment requested in aligned_alloc: 64, alignment must be a power of two and the requested size 0x64 must be a multiple of alignment (thread T0) I really don't like that mixing of decimal alignment and hex size. There's no way with ASAN to see all the errors. It exists at the first error and says HINT: if you don't care about these errors you may set allocator_may_return_null=1 which turns off all these kinds of errors. ASAN doesn't complain about memalign/aligned_alloc size of zero. I've fixed the failure. I'll update the BadSize message and cause later. commit 8ec7405afb8fe610c46582e74d7572e5a6f4cd6c (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd <pjfloyd@wanadoo.fr> Date: Fri Sep 5 09:04:16 2025 +0200 Bug 509107 - memcheck/tests/duplicate_align_size_errors.cpp fails |
Created attachment 184712 [details] stderr diff Observed on s390 and amd64 with git revision 6902553f902e6 built from scratch. glibc version is 2.35 on both platforms. So it seems that instead of aligned_alloc function memalign is called. memalign does not have the constraint that size should be a multiple of the request alignment. Which explains the missing complaint. This aligned_alloc -> memalign replacement is not caused by some ifdeffery in header files as objdump --disassemble=main does not refer to memalign. Looks like valgrind's malloc replacement machinery may be causing it.