Re: qsort() issue on ARM

["Piotr Gaweł" <piotr.krzysztof.gawel@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3520 bytes --]

Good point. Thank You very much Rich! I already noticed that LTP has a lot
of bugs. I will fix it in my distribution.

Many thanks for the support.
Have a nice day.

Best regards,
Piotr


wt., 23 lip 2019, 16:24 użytkownik Rich Felker <dalias@libc.org> napisał:

> On Tue, Jul 23, 2019 at 04:09:04PM +0200, piotr.krzysztof.gawel wrote:
> > Hi MUSL developers,
> >
> > I encountered an issue when running LTP tests on my ARM A15 machine.
> Tests executed with tst_timer_test where dumping cores. Further analysis of
> tst_timer_test.c file led me to qsort() function which they call. Their
> >  code relies on sorted array.
> > I wrote a sample application which you may find in attachment. Here is
> the output from that tool on my machine:
> > # /media/qsort
> > Before sorting:
> > 00: 100126
> > 01: 100193
> > 02: 100143
> > 03: 100131
> > 04: 100129
> > 05: 100129
> > 06: 100128
> > 07: 100128
> > 08: 100125
> > 09: 100125
> >
> > Samples number: 10, width: 8
> >    cmp: comparing 100143 with 100126 (0)
> >    ...
> >    cmp: comparing 100143 with 100131 (0)
> >    cmp: comparing 100126 with 100193 (1)
> >
> >
> > After sorting:
> > 00: 100193
> > 01: 100126
> > 02: 100143
> > 03: 100131
> > 04: 100129
> > 05: 100129
> > 06: 100128
> > 07: 100128
> > 08: 100125
> > 09: 100125
> > Before sorting:
> > 00: 100126
> > 01: 100193
> > 02: 100143
> > 03: 100131
> > 04: 100129
> > 05: 100129
> > 06: 100128
> > 07: 100128
> > 08: 100125
> > 09: 100125
> >
> > Samples number: 10, width: 8
> >    cmp: comparing 100143 with 100126 (0)
> > ...
> >    cmp: comparing 100126 with 100193 (1)
> >
> >
> > After sorting:
> > 00: 100193
> > 01: 100126
> > 02: 100143
> > 03: 100131
> > 04: 100129
> > 05: 100129
> > 06: 100128
> > 07: 100128
> > 08: 100125
> > 09: 100125
> >
> > Observations from that output:
> >
> > comparison function works as expectedarray is sorted from max to min
> > value as expected except second item (index 01) which looks like a
> > bugarray on heap and stack presents exactly the same problem
> >
> > In case of LTP, the issue was more random – it was not always second
> > item in wrong position, items were more disordered.
> > When I compiled the testing app for my PC (x86_64) with GNU libc
> > (Ubuntu), array was sorted correctly.
> >
> > I use gcc toolchain from Yocto. Whole image, including toolchain,
> > LTP and musl are built with Yocto.
> >
> > Thanks for any help or suggestion in advance! I’m looking forward to
> > hear from you if this is machine/architecture related issue, or if
> > you can see it also in your system. Please also add me to replies if
> > possible since I am not subscribed to mailing list.
>
> Their code just has undefined behavior by violating the contract of
> qsort with the cmp function they submit to it:
>
>
> https://github.com/linux-test-project/ltp/blob/4053a2551b926d372dd47485f7381ec3fa19772a/lib/tst_timer_test.c#L170
>
> qsort requires that the comparison return a negative, zero, or
> positive value depending on whether the relationship is less-than,
> equal, or greater-than. In particular, if cmp(a,b) is positive,
> cmp(b,a) must be negative, and vice versa. In one direction,
> cmp(100126,100193) is reporting them unequal, while in the other
> direction, cmp(100193,100126) is reporting them equal.
>
> FYI, LTP (and the OPTS code lots of it is derived from) has *lots* of
> UB/invalid-tests...
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 4584 bytes --]