[RFC] Remove EXIT_UNSUPPORTED in stdlib/test-bz22786 if path is NULL

[RFC] Remove EXIT_UNSUPPORTED in stdlib/test-bz22786 if path is NULL

[Stefan Liebler]

With commit 6c3a8a9d868a8deddf0d6dcc785b6d120de90523 (2018-08-25), the test
used xmalloc instead of malloc and therefore removed the path == NULL check
as xmalloc is printing an error message and exit with a fail in this case.

On s390-32 this was always a FAIL instead of UNSUPPORTED, thus the previous
behaviour was re-enabled with commit 3bad2358d67d371497079bba4f8eca9c0096f4e2
five days later on 2018-08-30. Therefore, we don't know if this also happens
on other systems.

While removing s390-32 with commit b01debcd8f5229860b3224ea135b1b8456281cee
I've adjusted the comment and Adhemerval asked whether this can also happen
on other systems with little physical memory.  We've decided to remove the
EXIT_UNSUPPORTED in this extra commit instead of the large s390-32 removal one.
See libc-alpha:
https://inbox.sourceware.org/libc-alpha/20260409085102.3475867-1-stli@linux.ibm.com/T/#m28b5375bef4cfb10729b93c7e658b91a14b07b85

If this change leads to test fails somewhere, please add a comment about your
used system and revert this commit.

Nowadays path is allocated with support_blob_repeat_allocate which returns
an empty struct in case of malloc/mmap is not able to allocate enough memory.
All other tests using support_blob_repeat_allocate
(stdlib/tst-strtod-overflow.c, support/tst-support_blob_repeat.c and
string/tst-memmove-overflow.c) are properly checking the start or size field
directly or indirectly via TEST_COMPARE_BLOB.
While the test support/tst-support_blob_repeat.c just prints a warning if
allocating the large mappings is not possible, the other tests exit with
UNSUPPORTED.

At least for the realpath-part, the commit
855a67c3cc81be4fc806c66e3e01b53e352a4e9f introduced support_accept_oom handling.
According to the discussion:
https://inbox.sourceware.org/libc-alpha/8a1fd5b2-5118-498e-babf-e46c0e6d1cdf@redhat.com/
Agreed, test-bz22786 can use a lot of memory.
OK. These convert OOM to UNSUPPORTED for the test if there isn't enough memory.

In case of not enough memory while allocating path, this change would lead to a
segmentation fault instead of UNSUPPORTED. As this is inconsistent compared to
the second realpath-part and also to the other tests using
support_blob_repeat_allocate, I would prefer keeping UNSUPPORTED if path is NULL.
Nevertheless, I've posted this patch for discussion as promised while reviewing
the s390-32 removal patch.
---
 stdlib/test-bz22786.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/stdlib/test-bz22786.c b/stdlib/test-bz22786.c
index 6e2636d896..494fc2adc7 100644
--- a/stdlib/test-bz22786.c
+++ b/stdlib/test-bz22786.c
@@ -43,13 +43,6 @@ do_test (void)
   struct support_blob_repeat repeat
     = support_blob_repeat_allocate ("a", 1, path_len);
   char *path = repeat.start;
-  if (path == NULL)
-    {
-      printf ("Repeated allocation (%zu bytes): %m\n", path_len);
-      /* On systems with little physical memory the test will
-	 fail and should be unsupported.  */
-      return EXIT_UNSUPPORTED;
-    }
 
   TEST_VERIFY_EXIT (symlink (".", lnk) == 0);
 
-- 
2.52.0

Re: [RFC] Remove EXIT_UNSUPPORTED in stdlib/test-bz22786 if path is NULL

[Adhemerval Zanella Netto]

On 23/04/26 09:43, Stefan Liebler wrote:
> With commit 6c3a8a9d868a8deddf0d6dcc785b6d120de90523 (2018-08-25), the test
> used xmalloc instead of malloc and therefore removed the path == NULL check
> as xmalloc is printing an error message and exit with a fail in this case.
> 
> On s390-32 this was always a FAIL instead of UNSUPPORTED, thus the previous
> behaviour was re-enabled with commit 3bad2358d67d371497079bba4f8eca9c0096f4e2
> five days later on 2018-08-30. Therefore, we don't know if this also happens
> on other systems.
> 
> While removing s390-32 with commit b01debcd8f5229860b3224ea135b1b8456281cee
> I've adjusted the comment and Adhemerval asked whether this can also happen
> on other systems with little physical memory.  We've decided to remove the
> EXIT_UNSUPPORTED in this extra commit instead of the large s390-32 removal one.
> See libc-alpha:
> https://inbox.sourceware.org/libc-alpha/20260409085102.3475867-1-stli@linux.ibm.com/T/#m28b5375bef4cfb10729b93c7e658b91a14b07b85
> 
> If this change leads to test fails somewhere, please add a comment about your
> used system and revert this commit.
> 
> Nowadays path is allocated with support_blob_repeat_allocate which returns
> an empty struct in case of malloc/mmap is not able to allocate enough memory.
> All other tests using support_blob_repeat_allocate
> (stdlib/tst-strtod-overflow.c, support/tst-support_blob_repeat.c and
> string/tst-memmove-overflow.c) are properly checking the start or size field
> directly or indirectly via TEST_COMPARE_BLOB.
> While the test support/tst-support_blob_repeat.c just prints a warning if
> allocating the large mappings is not possible, the other tests exit with
> UNSUPPORTED.
> 
> At least for the realpath-part, the commit
> 855a67c3cc81be4fc806c66e3e01b53e352a4e9f introduced support_accept_oom handling.
> According to the discussion:
> https://inbox.sourceware.org/libc-alpha/8a1fd5b2-5118-498e-babf-e46c0e6d1cdf@redhat.com/
> Agreed, test-bz22786 can use a lot of memory.
> OK. These convert OOM to UNSUPPORTED for the test if there isn't enough memory.
> 
> In case of not enough memory while allocating path, this change would lead to a
> segmentation fault instead of UNSUPPORTED. As this is inconsistent compared to
> the second realpath-part and also to the other tests using
> support_blob_repeat_allocate, I would prefer keeping UNSUPPORTED if path is NULL.
> Nevertheless, I've posted this patch for discussion as promised while reviewing
> the s390-32 removal patch.

LGTM, thanks.  I think I haven't seem any failure besides s390.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

> ---
>  stdlib/test-bz22786.c | 7 -------
>  1 file changed, 7 deletions(-)
> 
> diff --git a/stdlib/test-bz22786.c b/stdlib/test-bz22786.c
> index 6e2636d896..494fc2adc7 100644
> --- a/stdlib/test-bz22786.c
> +++ b/stdlib/test-bz22786.c
> @@ -43,13 +43,6 @@ do_test (void)
>    struct support_blob_repeat repeat
>      = support_blob_repeat_allocate ("a", 1, path_len);
>    char *path = repeat.start;
> -  if (path == NULL)
> -    {
> -      printf ("Repeated allocation (%zu bytes): %m\n", path_len);
> -      /* On systems with little physical memory the test will
> -	 fail and should be unsupported.  */
> -      return EXIT_UNSUPPORTED;
> -    }
>  
>    TEST_VERIFY_EXIT (symlink (".", lnk) == 0);
>  

Re: [RFC] Remove EXIT_UNSUPPORTED in stdlib/test-bz22786 if path is NULL

[Stefan Liebler]

On 4/27/26 15:19, Adhemerval Zanella Netto wrote:
> 
> 
> On 23/04/26 09:43, Stefan Liebler wrote:
>> With commit 6c3a8a9d868a8deddf0d6dcc785b6d120de90523 (2018-08-25), the test
>> used xmalloc instead of malloc and therefore removed the path == NULL check
>> as xmalloc is printing an error message and exit with a fail in this case.
>>
>> On s390-32 this was always a FAIL instead of UNSUPPORTED, thus the previous
>> behaviour was re-enabled with commit 3bad2358d67d371497079bba4f8eca9c0096f4e2
>> five days later on 2018-08-30. Therefore, we don't know if this also happens
>> on other systems.
>>
>> While removing s390-32 with commit b01debcd8f5229860b3224ea135b1b8456281cee
>> I've adjusted the comment and Adhemerval asked whether this can also happen
>> on other systems with little physical memory.  We've decided to remove the
>> EXIT_UNSUPPORTED in this extra commit instead of the large s390-32 removal one.
>> See libc-alpha:
>> https://inbox.sourceware.org/libc-alpha/20260409085102.3475867-1-stli@linux.ibm.com/T/#m28b5375bef4cfb10729b93c7e658b91a14b07b85
>>
>> If this change leads to test fails somewhere, please add a comment about your
>> used system and revert this commit.
>>
>> Nowadays path is allocated with support_blob_repeat_allocate which returns
>> an empty struct in case of malloc/mmap is not able to allocate enough memory.
>> All other tests using support_blob_repeat_allocate
>> (stdlib/tst-strtod-overflow.c, support/tst-support_blob_repeat.c and
>> string/tst-memmove-overflow.c) are properly checking the start or size field
>> directly or indirectly via TEST_COMPARE_BLOB.
>> While the test support/tst-support_blob_repeat.c just prints a warning if
>> allocating the large mappings is not possible, the other tests exit with
>> UNSUPPORTED.
>>
>> At least for the realpath-part, the commit
>> 855a67c3cc81be4fc806c66e3e01b53e352a4e9f introduced support_accept_oom handling.
>> According to the discussion:
>> https://inbox.sourceware.org/libc-alpha/8a1fd5b2-5118-498e-babf-e46c0e6d1cdf@redhat.com/
>> Agreed, test-bz22786 can use a lot of memory.
>> OK. These convert OOM to UNSUPPORTED for the test if there isn't enough memory.
>>
>> In case of not enough memory while allocating path, this change would lead to a
>> segmentation fault instead of UNSUPPORTED. As this is inconsistent compared to
>> the second realpath-part and also to the other tests using
>> support_blob_repeat_allocate, I would prefer keeping UNSUPPORTED if path is NULL.
>> Nevertheless, I've posted this patch for discussion as promised while reviewing
>> the s390-32 removal patch.
> 
> LGTM, thanks.  I think I haven't seem any failure besides s390.
> 
> Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
> 
Okay. Thanks. I've just committed the patch.

Bye,
Stefan
>> ---
>>  stdlib/test-bz22786.c | 7 -------
>>  1 file changed, 7 deletions(-)
>>
>> diff --git a/stdlib/test-bz22786.c b/stdlib/test-bz22786.c
>> index 6e2636d896..494fc2adc7 100644
>> --- a/stdlib/test-bz22786.c
>> +++ b/stdlib/test-bz22786.c
>> @@ -43,13 +43,6 @@ do_test (void)
>>    struct support_blob_repeat repeat
>>      = support_blob_repeat_allocate ("a", 1, path_len);
>>    char *path = repeat.start;
>> -  if (path == NULL)
>> -    {
>> -      printf ("Repeated allocation (%zu bytes): %m\n", path_len);
>> -      /* On systems with little physical memory the test will
>> -	 fail and should be unsupported.  */
>> -      return EXIT_UNSUPPORTED;
>> -    }
>>  
>>    TEST_VERIFY_EXIT (symlink (".", lnk) == 0);
>>  
>