From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14435 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?UGlvdHIgR2F3ZcWC?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: qsort() issue on ARM Date: Tue, 23 Jul 2019 17:14:40 +0200 Message-ID: References: <5d371501.1c69fb81.faf79.0578@mx.google.com> <20190723142439.GA23142@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000877b93058e5aa79e" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="258973"; mail-complaints-to="usenet@blaine.gmane.org" Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-14451-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 23 17:15:12 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hpwVS-00157n-MU for gllmg-musl@m.gmane.org; Tue, 23 Jul 2019 17:15:11 +0200 Original-Received: (qmail 22125 invoked by uid 550); 23 Jul 2019 15:15:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22098 invoked from network); 23 Jul 2019 15:15:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e6gMMMbthCKkiy/ojlpHYsRiS178JTrDe4hk3wbpJ1s=; b=KKunttTSkEdKJ3qwnLuKryl+XPAUb/cH6vPgX95fX1xNtG3S2sjgEuQvrqaAOfXxNK wfT2RC1NxCIOQXWrgVA3KUq2lV5ALZuyRZjYx14GhKumHsFifstEazEttH19GgNFxKpV 1QBUc7bJY5S98GURWbYwNCcX/NGWgbHrYaOCC5J004fwUOOtk153NQvR2paD+WOsHI+8 7TPES+T5XhaBjJFUcWRTfn6YE1OcCNlfTrMDKahIBz1oOfja2sTU/D3K2s7C/OpOHLoI Hc53hl7sJEMs0b5pgZ28EewahwRDFZJvO1J816WzhyipcbmYvwBZyrBj44O6ieFWiNnv k31g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e6gMMMbthCKkiy/ojlpHYsRiS178JTrDe4hk3wbpJ1s=; b=cEVviwEBc3VGpfg8kvrUBtPjwTSbSd3XaB9hlpxu4fvcsRf5tkdehHDWHBfjOQMU1k IR4C5gzup5VvWIFiOPI19nbR01oheYPJNdgPLQu8MuEvarJS2PvrvO1VbV/g0TGMXx0y MeVqMSsRF3oCk6/S6ct7pWkdBxrCVyGRKAj8H+ZGgGb0W3RX2DSZzBtmUZSW0UDnqrMH b2uHM/usDwPmC5qXCn6FoOeoqXoHC2sFeiGdFs/3oqPqk5xle4aAA2J+vcHrYfA3L9cS 02umTY/ES7WbPVRFFhM49Qv+sAi+XvZrBuPRvqu6Y9PWBmEEWOgMHdYlntzqrWT6hPVE EflQ== X-Gm-Message-State: APjAAAVf3OxM6GzPiilI3i4EcrgEOxJ8x+Cer2Q20AvX6MORjMurPfrj ySF81qQV2cRTx8HXBsCbm0WTH8ja1SubsbLlpW0= X-Google-Smtp-Source: APXvYqykiTkHpxHOTxzw/4Ec3z0bOm5kibnaHTjv0LlGn6vEohXD2peHE5xLOFruZ3FgifCp5N4N7IkDb48JCfCogqg= X-Received: by 2002:a1c:4803:: with SMTP id v3mr70533748wma.49.1563894892426; Tue, 23 Jul 2019 08:14:52 -0700 (PDT) In-Reply-To: <20190723142439.GA23142@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14435 Archived-At: --000000000000877b93058e5aa79e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C5=BCytkownik Rich Felker napis= a=C5=82: > 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 =E2=80=93 it was not always s= econd > > 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=E2=80=99m looking forwa= rd 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/4053a2551b926d372dd47485f7= 381ec3fa19772a/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 > --000000000000877b93058e5aa79e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good point. Thank You very much Rich! I already noti= ced that LTP has a lot of bugs. I will fix it in my distribution.=C2=A0
Many thanks for the support.
Have a nice day.=C2=A0

=
Best regards,
Piotr=C2=A0

wt., = 23 lip 2019, 16:24 u=C5=BCytkownik Rich Felker <dalias@libc.org> napisa=C5=82:
On Tue, Jul 23, 2019 at 04:09:04PM +0200, piotr.krzysztof.gaw= el wrote:
> Hi MUSL developers,
> =C2=A0
> I encountered an issue when running LTP tests on my ARM A15 machine. T= ests 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
>=C2=A0 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
> =C2=A0
> Samples number: 10, width: 8
> =C2=A0=C2=A0 cmp: comparing 100143 with 100126 (0)
> =C2=A0=C2=A0 ...
> =C2=A0=C2=A0 cmp: comparing 100143 with 100131 (0)
> =C2=A0=C2=A0 cmp: comparing 100126 with 100193 (1)
> =C2=A0
> =C2=A0
> 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
> =C2=A0
> Samples number: 10, width: 8
> =C2=A0=C2=A0 cmp: comparing 100143 with 100126 (0)
> ...
> =C2=A0=C2=A0 cmp: comparing 100126 with 100193 (1)
> =C2=A0
> =C2=A0
> After sorting:
> 00: 100193
> 01: 100126
> 02: 100143
> 03: 100131
> 04: 100129
> 05: 100129
> 06: 100128
> 07: 100128
> 08: 100125
> 09: 100125
> =C2=A0
> 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
> =C2=A0
> In case of LTP, the issue was more random =E2=80=93 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.
> =C2=A0
> I use gcc toolchain from Yocto. Whole image, including toolchain,
> LTP and musl are built with Yocto.
> =C2=A0
> Thanks for any help or suggestion in advance! I=E2=80=99m looking forw= ard 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/4053= a2551b926d372dd47485f7381ec3fa19772a/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
--000000000000877b93058e5aa79e--