On Wednesday 25 June 2025 20:53:10 Martin Storsjö wrote:
> On Wed, 25 Jun 2025, Pali Rohár wrote:
>
> > On Wednesday 25 June 2025 11:08:57 Martin Storsjö wrote:
> > > Both for UCRT and for msvcrt.dll, we end up calling the CRT DLL
> > > provided functions directly, so these issues are outside of our
> > > own emulation wrappers.
> > >
> > > Just waive the test for these configurations.
> > >
> > > Signed-off-by: Martin Storsjö <mar...@martin.st>
> > > ---
> > > mingw-w64-crt/testcases/t_aligned_alloc.c | 30 ++++++++++++++++++-----
> > > 1 file changed, 24 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/mingw-w64-crt/testcases/t_aligned_alloc.c
> > > b/mingw-w64-crt/testcases/t_aligned_alloc.c
> > > index 1e4cbdea2..d80a3d318 100644
> > > --- a/mingw-w64-crt/testcases/t_aligned_alloc.c
> > > +++ b/mingw-w64-crt/testcases/t_aligned_alloc.c
> > > @@ -25,6 +25,18 @@
> > > } \
> > > } while (0)
> > >
> > > +#ifndef BROKEN_REALLOC_SHRINK
> > > +#if defined(__aarch64__)
> > > +/* On aarch64, both UCRT and msvcrt.dll, a _aligned_realloc that
> > > attempts to
> > > + * shrink the allocation, ends up not shrinking it in practice, leading
> > > to
> > > + * failures in some of these tests. Ignore those test failures. This is
> > > + * observed on both Windows 10 rev 19041 and Windows 11 rev 22000 and
> > > 22631. */
> > > +#define BROKEN_REALLOC_SHRINK 1
> > > +#else
> > > +#define BROKEN_REALLOC_SHRINK 0
> > > +#endif
> > > +#endif
> > > +
> > > int main() {
> > > void *ptr;
> > > size_t size;
> > > @@ -94,17 +106,20 @@ int main() {
> > > TEST((uintptr_t)ptr % 128, 0, "_aligned_realloc: ptr 0x%p is not
> > > aligned", ptr);
> > >
> > > size = _aligned_msize(ptr, 128, 0);
> > > - TEST(size, 10, "_aligned_msize: ptr 0x%p has incorrect size %lu", ptr,
> > > (unsigned long)size);
> > > + if (!BROKEN_REALLOC_SHRINK)
> > > + TEST(size, 10, "_aligned_msize: ptr 0x%p has incorrect size %lu",
> > > ptr, (unsigned long)size);
> > >
> > > ptr = _aligned_recalloc(ptr, 20, 1, 128);
> > > assert(ptr != NULL);
> > > TEST((uintptr_t)ptr % 128, 0, "_aligned_recalloc: ptr 0x%p is not
> > > aligned", ptr);
> > >
> > > size = _aligned_msize(ptr, 128, 0);
> > > - TEST(size, 20, "_aligned_msize: ptr 0x%p has incorrect size %lu", ptr,
> > > (unsigned long)size);
> > > + if (!BROKEN_REALLOC_SHRINK)
> > > + TEST(size, 20, "_aligned_msize: ptr 0x%p has incorrect size %lu",
> > > ptr, (unsigned long)size);
> > >
> > > TEST_MEM(ptr, 0x02, 10, "_aligned_realloc: 0x%p has incorrect byte
> > > 0x%02x at %lu", ptr, ((unsigned char *)ptr)[i], (unsigned long)i);
> >
> > Not related to your change. But now I spotted typo in the above TEST_MEM
> > message. There is "_aligned_realloc", but it should be "_aligned_recalloc"
> > (missing "c").
>
> Ok, I can make a commit to fix that and push along with other changes.
>
> > > - TEST_MEM(ptr+10, 0x00, 10, "_aligned_recalloc: 0x%p has incorrect byte
> > > 0x%02x at %lu", ptr, ((unsigned char *)ptr)[i+10], (unsigned long)i+10);
> > > + if (!BROKEN_REALLOC_SHRINK)
> > > + TEST_MEM(ptr+10, 0x00, 10, "_aligned_recalloc: 0x%p has incorrect
> > > byte 0x%02x at %lu", ptr, ((unsigned char *)ptr)[i+10], (unsigned
> > > long)i+10);
> >
> > Why is this test also skipped? Does it mean that _aligned_recalloc does
> > not fill zero bytes as "c"alloc is suppose to do?
>
> I think it does fill with zeros, when it actually ends up expanding for
> real.
>
> But first we allocate 128, then we shrink it to 10, then we expand to 20. As
> the realloc/recalloc to shrink it to 10 actually doesn't seem to shrink it
> (but keeps the size as 128) due to this issue, it means that the recalloc to
> expand from 10 to 20 doesn't zero the range [10,20] either, since the
> allocation at this time is 128, not 10.
Ou, I see. It is not just that *msize() function returns incorrect value.
It also affects the _aligned_recalloc() and make it misbehaving.
> So with _aligned_recalloc, it seems like this issue really could cause
> trouble for potential users. Not to the point that I think we should try to
> work around it in mingw-w64-crt, but perhaps we should file it as a bug to
> MS.
>
> // Martin
It makes sense to fill a bug to MS. But I have no idea who can do that
and how it can be done.
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
