Bug 509107 - memcheck/tests/duplicate_align_size_errors.cpp fails
Summary: memcheck/tests/duplicate_align_size_errors.cpp fails
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Paul Floyd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-09-04 14:35 UTC by Florian Krohm
Modified: 2025-09-05 07:05 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
stderr diff (842 bytes, patch)
2025-09-04 14:35 UTC, Florian Krohm
Details
duplicate_align_size_errors.objdump (4.61 KB, text/plain)
2025-09-04 14:36 UTC, Florian Krohm
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Krohm 2025-09-04 14:35:18 UTC
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.
Comment 1 Florian Krohm 2025-09-04 14:36:05 UTC
Created attachment 184713 [details]
duplicate_align_size_errors.objdump
Comment 2 Paul Floyd 2025-09-04 15:52:29 UTC
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.
Comment 3 Paul Floyd 2025-09-05 07:05:56 UTC
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