* qsort() issue on ARM @ 2019-07-23 14:09 piotr.krzysztof.gawel 2019-07-23 14:24 ` Rich Felker 0 siblings, 1 reply; 3+ messages in thread From: piotr.krzysztof.gawel @ 2019-07-23 14:09 UTC (permalink / raw) To: musl [-- Attachment #1.1: Type: text/plain, Size: 2068 bytes --] 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. Best regards, Piotr Gawel null [-- Attachment #1.2: Type: text/html, Size: 12988 bytes --] [-- Attachment #2: qsort.c --] [-- Type: application/c, Size: 1430 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: qsort() issue on ARM 2019-07-23 14:09 qsort() issue on ARM piotr.krzysztof.gawel @ 2019-07-23 14:24 ` Rich Felker 2019-07-23 15:14 ` Piotr Gaweł 0 siblings, 1 reply; 3+ messages in thread From: Rich Felker @ 2019-07-23 14:24 UTC (permalink / raw) To: piotr.krzysztof.gawel; +Cc: musl 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: qsort() issue on ARM 2019-07-23 14:24 ` Rich Felker @ 2019-07-23 15:14 ` Piotr Gaweł 0 siblings, 0 replies; 3+ messages in thread From: Piotr Gaweł @ 2019-07-23 15:14 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-07-23 15:14 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-23 14:09 qsort() issue on ARM piotr.krzysztof.gawel 2019-07-23 14:24 ` Rich Felker 2019-07-23 15:14 ` Piotr Gaweł
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).