This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: while working on an optimized version of strnlen, some string tests fail


This is my current 'make check' result.

XPASS: elf/tst-protected1a
XPASS: elf/tst-protected1b
FAIL: malloc/tst-malloc-thread-fail
UNSUPPORTED: math/test-nearbyint-except-2
FAIL: nptl/tst-cancel24-static
FAIL: posix/tst-getaddrinfo5
Summary of test results:
         3 FAIL
   2432 PASS
         1 UNSUPPORTED
       43 XFAIL
         2 XPASS

malloc/tst-malloc-thread-fail.out says "Timed out: killed the child process".
Is it possible that this test failure relates to something with my
test environment, rather than my implementation?
I'm testing on an ODROID-XU4 board.

nptl/tst-cancel24-static.out says "Didn't expect signal from child:
got `Segmentation fault'"
and this failure is mentioned at
<https://sourceware.org/glibc/wiki/Release/2.24#Build_and_test_issues>.
(I'm running the test case on the 2.24 version branch).

posix/tst-getaddrinfo5 seems to fail because my test board does not
have an internet connection.

Is it okay to ignore tests listed as UNSUPPORTED, XFAIL, and XPASS?

2016-11-18 3:52 GMT+09:00 Adhemerval Zanella <adhemerval.zanella@linaro.org>:
>
>
> On 17/11/2016 16:27, Nam-goo Lee wrote:
>> Hi.
>>
>> I'm working on an optimized version of strnlen function for arm.
>> But following tests fail, and I'm stuck here finding the reasons for
>> the failure.
>>
>> FAIL: string/stratcliff
>> FAIL: string/test-stpncpy
>> FAIL: string/test-strncpy
>> Summary of test results:
>>       3 FAIL
>>      57 PASS
>>
>> I'm surprised to see that tests for functions other than strnlen fail.
>> I'd really appreciate to get some hints on what the 'stratcliff' test does,
>> and the reasons for the failure.
>> Attached my code.
>>
>> Thanks.
>>
>
> Hi,
>
> ARM uses default string/str{n,p}cpy.c code and strncpy code has:
>
>  26 char *
>  27 STRNCPY (char *s1, const char *s2, size_t n)
>  28 {
>  29   size_t size = __strnlen (s2, n);
>
> So if your optimized strnlen does not provide the expected correct result
> the code will potentially fail.  It might the case where it is stressing
> a case that test-strnlen does not issue.  Either way, you need to a full
> clean make check to make sure the implementation is ready for upstream review.

Attachment: strnlen.S
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]