[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 23 Jul 2019 17:14:40 +0200
From: Piotr Gaweł <piotr.krzysztof.gawel@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: qsort() issue on ARM
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@...c.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
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
