NetBSD Problem Report #53277

From gson@gson.org  Fri May 11 15:45:49 2018
Return-Path: <gson@gson.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 613AF7A1E5
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 11 May 2018 15:45:49 +0000 (UTC)
Message-Id: <20180511154542.9CC6A98B44C@guava.gson.org>
Date: Fri, 11 May 2018 18:45:42 +0300 (EEST)
From: gson@gson.org (Andreas Gustafsson)
Reply-To: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@NetBSD.org
Subject: Many ubsan tests fail on sparc
X-Send-Pr-Version: 3.95

>Number:         53277
>Notify-List:    riastradh@NetBSD.org
>Category:       port-sparc
>Synopsis:       Many ubsan tests fail on sparc
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    martin
>State:          needs-pullups
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 11 15:50:00 +0000 2018
>Closed-Date:    
>Last-Modified:  Fri Apr 18 23:35:01 +0000 2025
>Originator:     Andreas Gustafsson
>Release:        NetBSD-current, source date >= 2018.05.02.18.46.05
>Organization:

>Environment:
System: NetBSD guava.gson.org 7.1.1 NetBSD 7.1.1 (GENERIC.201712222334Z) amd64
Architecture: sparc
Machine: sparc
>Description:

The number of failing test cases on the sparc testbed jumped from 11 to 50
with the following commits:

  2018.05.02.18.46.05 kamil src/distrib/sets/lists/tests/mi 1.782
  2018.05.02.18.46.05 kamil src/tests/usr.bin/c++/Makefile 1.9
  2018.05.02.18.46.05 kamil src/tests/usr.bin/c++/t_ubsan_int_add_overflow.sh 1.1
  2018.05.02.18.46.05 kamil src/tests/usr.bin/c++/t_ubsan_int_divzero.sh 1.1
  2018.05.02.18.46.05 kamil src/tests/usr.bin/c++/t_ubsan_int_neg_overflow.sh 1.1
  2018.05.02.18.46.05 kamil src/tests/usr.bin/c++/t_ubsan_int_sub_overflow.sh 1.1
  2018.05.02.18.46.05 kamil src/tests/usr.bin/c++/t_ubsan_vla_out_of_bounds.sh 1.1
  2018.05.02.18.46.05 kamil src/tests/usr.bin/cc/Makefile 1.4
  2018.05.02.18.46.05 kamil src/tests/usr.bin/cc/t_ubsan_int_add_overflow.sh 1.1
  2018.05.02.18.46.05 kamil src/tests/usr.bin/cc/t_ubsan_int_divzero.sh 1.1
  2018.05.02.18.46.05 kamil src/tests/usr.bin/cc/t_ubsan_int_neg_overflow.sh 1.1
  2018.05.02.18.46.05 kamil src/tests/usr.bin/cc/t_ubsan_int_sub_overflow.sh 1.1
  2018.05.02.18.46.05 kamil src/tests/usr.bin/cc/t_ubsan_vla_out_of_bounds.sh 1.1

>How-To-Repeat:

Inspect the test reports at

  http://releng.netbsd.org/b5reports/sparc/commits-2018.05.html#2018.05.02.18.46.05

>Fix:

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: port-sparc-maintainer->kamil
Responsible-Changed-By: gson@NetBSD.org
Responsible-Changed-When: Fri, 11 May 2018 16:00:15 +0000
Responsible-Changed-Why:
Over to committer


From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/53277: Many ubsan tests fail on sparc
Date: Fri, 11 May 2018 18:03:04 +0200

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --HQtdCKtPqRNo2xPyNXKLpUF6AatvW3CRA
 Content-Type: multipart/mixed; boundary="T5npjsQ3e824A6QgsYJiQc7n4qWWt7fxk";
  protected-headers="v1"
 From: Kamil Rytarowski <n54@gmx.com>
 To: gnats-bugs@NetBSD.org
 Message-ID: <1944678e-2109-3f6b-4a77-0f8608fdf2cd@gmx.com>
 Subject: Re: port-sparc/53277: Many ubsan tests fail on sparc
 References: <pr-port-sparc-53277@gnats.netbsd.org>
  <20180511154542.9CC6A98B44C@guava.gson.org>
  <20180511155000.3A7FF7A159@mollari.NetBSD.org>
 In-Reply-To: <20180511155000.3A7FF7A159@mollari.NetBSD.org>

 --T5npjsQ3e824A6QgsYJiQc7n4qWWt7fxk
 Content-Type: text/plain; charset=utf-8
 Content-Language: en-US
 Content-Transfer-Encoding: quoted-printable

 Timeout.

 We can either bump the time limit or skip them for slow ports.


 --T5npjsQ3e824A6QgsYJiQc7n4qWWt7fxk--

 --HQtdCKtPqRNo2xPyNXKLpUF6AatvW3CRA
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"

 -----BEGIN PGP SIGNATURE-----

 iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAlr1vrgMHG41NEBnbXgu
 Y29tAAoJEEuzCOmwLnZs6LwP/iEZDjR77CAmzi5hfD/eFCAvIdILDKJYH3cUXxTQ
 7N00QVx10uJheoA3LHvGk7b0yX8+1yHFQ9ocYyFwkTJKSnqMlwWcrTukbAizcmC5
 9ZQ8Vk7535BwtnH2vGo3rYfOGPx8/Vd7nBo7G/9BTSM446jbgRu7NfWxE2S+3QSw
 JMDBYpzQwl7ykjX0u/JQ3uBV//gnrQ0g/hvNlmgEY56YrQEFMLCiNtJOXSDeBafP
 vB761HqsEgO303O0jJcpeOUL9quH6i8GstHG/DMMLh9Ptf0HNpsaPCcdLDq0rH1c
 XWZr4ScUy08OHkJFHW60OHHJrOSejXQbeuGrSN+mq/RYxwQMOxwtNVXlNyT5F93d
 CUHf49HBT+mBCysAQlwEx1j51NVy5wCECfjeYdPwkUIfnEG9rqGV94At/JMxKrxq
 WVXrVwcC4wfMOd0PfETOPuH4AYl8Kchv5ulyBOP7JbpugoU2otktE1HN7TUrIqpr
 oqq4Ok+FHzcQIYewhZvlNzGDrlH1/3BKxtJbjpaw+6LXCpAbUE+bNiKLjpuSeWsF
 W+Nw2dybMFgIVi06gzSvTlYmUa5TO+2UAiguM121AVgGluSB3h+XCYE1r2lkFmvK
 DsU7+8IFXXt/BHEywmS69l1KYmubGn5SSTrA7a6o6Z3iY81c0GRssfYjiLKILL3/
 CsBh
 =405v
 -----END PGP SIGNATURE-----

 --HQtdCKtPqRNo2xPyNXKLpUF6AatvW3CRA--

Responsible-Changed-From-To: kamil->martin
Responsible-Changed-By: martin@NetBSD.org
Responsible-Changed-When: Fri, 11 May 2018 16:07:47 +0000
Responsible-Changed-Why:
Take


From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: kamil@NetBSD.org, Andreas Gustafsson <gson@gson.org>
Subject: Re: port-sparc/53277: Many ubsan tests fail on sparc
Date: Fri, 11 May 2018 18:06:55 +0200

 On Fri, May 11, 2018 at 04:05:01PM +0000, Kamil Rytarowski wrote:

 >  Timeout.
 >  
 >  We can either bump the time limit or skip them for slow ports.

 Let me test them on real sparc hardware and analyze it properly.

 Martin

From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/53277: Many ubsan tests fail on sparc
Date: Fri, 11 May 2018 18:14:46 +0200

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --VJxMClt5xK1a58vDilbZBiZw5h3NdzSYk
 Content-Type: multipart/mixed; boundary="VEOcOHG2eiIBXMexvgYbr6KeNpsHZduOE";
  protected-headers="v1"
 From: Kamil Rytarowski <n54@gmx.com>
 To: gnats-bugs@NetBSD.org
 Message-ID: <a076f444-2d38-8de6-2bdd-04bbfdb70bb0@gmx.com>
 Subject: Re: port-sparc/53277: Many ubsan tests fail on sparc
 References: <pr-port-sparc-53277@gnats.netbsd.org>
  <20180511154542.9CC6A98B44C@guava.gson.org>
  <20180511160501.961017A183@mollari.NetBSD.org>
  <20180511160655.GB5478@mail.duskware.de>
 In-Reply-To: <20180511160655.GB5478@mail.duskware.de>

 --VEOcOHG2eiIBXMexvgYbr6KeNpsHZduOE
 Content-Type: text/plain; charset=utf-8
 Content-Language: en-US
 Content-Transfer-Encoding: quoted-printable

 On 11.05.2018 18:06, Martin Husemann wrote:
 > On Fri, May 11, 2018 at 04:05:01PM +0000, Kamil Rytarowski wrote:
 >=20
 >>  Timeout.
 >> =20
 >>  We can either bump the time limit or skip them for slow ports.
 >=20
 > Let me test them on real sparc hardware and analyze it properly.
 >=20
 > Martin
 >=20

 Something still could be wrong with ucontext macros that could cause hang=
 =2E


 --VEOcOHG2eiIBXMexvgYbr6KeNpsHZduOE--

 --VJxMClt5xK1a58vDilbZBiZw5h3NdzSYk
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"

 -----BEGIN PGP SIGNATURE-----

 iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAlr1wXYMHG41NEBnbXgu
 Y29tAAoJEEuzCOmwLnZsOyoQAJ/pkNjuOJVwDgxRbBQAdfkJpzwRn0TR+/ketbIC
 IX9zEyyO3bYq4T3STZItnmdTKNVg0SZcJuOC52zFKh0mylVRfGb6cNFAijj2cQxz
 6Fgo48bpodetLoIfaDao28HZwJGgghrREgvDV8ihCkgEsediqW7m6lSdyp3ad4GI
 CwppxP2MwHkOTAX18djjJcufFqG9TPbCGETJAwaTilOYBgMCap8vaNw1iHX8buvC
 y4t+aY85vzhPxi/i9VtzAmkNkr2Q4tuBcAaUeObzrwbqRvI9AcY2BCqxC6ZdOEqd
 tQN9Tt2RFsRJ0uOhfa2xUpVqhK4SKr+FSxINSHv46ygcxV3vera3yCMDTzRKHSrZ
 sM7QDZgqHo0AqTTDe4OkoYxLmjfjXgKoceWjKPEz8EisuFPkLeZgZD9R27EWx7EM
 OhasHCxmJoL6dDXR1wgYA+vgwjEIi70fDAX91l5hDN9sZXlb3g9ngwn9f8ycvvVZ
 6/BEMWay2LkBUvqQRJhOO7UCbyGGgrv3O0XXTzQ77Z/ZwpZMG6Y20XJUeZHVuZm+
 JPm/Vm2XyXtLz2MpLtSE67kTlh58Hwf3i/addHW19EwKcb+UMhn4dCmYx0MRFgJ5
 Td0ZiP/FH5lhGA9uwn9hbGhMPKzbAgcAmXPbKRlrDcQqoqrAKLDunNoKt7r/3VX6
 kUP8
 =gPXU
 -----END PGP SIGNATURE-----

 --VJxMClt5xK1a58vDilbZBiZw5h3NdzSYk--

State-Changed-From-To: open->analyzed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 18 Apr 2025 22:37:27 +0000
State-Changed-Why:
I tried compiling and running the t_ubsan_int_add_overflow program on
sparc under anita:

$ cat >test.c
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
int help(int);
#ifndef PIC_MAIN
int help(int count) {volatile int l = INT_MAX; l+= count; return l;}
#endif
#ifndef PIC_FOO
int main(int argc, char **argv) {volatile int l = INT_MAX; l+=argc; return l;}
#endif
$ cc -fsanitize=undefined -o test test.c
$ ./test

It didn't seem to react, but ^T showed the same instruction address
repeatedly:

[ 5401.0213825] load: 0.65  cmd: test 1508 [0xed9c9454] 4.06u 46.48s 90% 2956k
[ 5403.7323765] load: 0.65  cmd: test 1508 [0xed9c9454] 4.22u 48.94s 91% 2956k
[ 5404.3214200] load: 0.65  cmd: test 1508 [0xed9c9454] 4.27u 49.45s 91% 2956k
[ 5404.4614085] load: 0.65  cmd: test 1508 [0xed9c9454] 4.30u 49.55s 91% 2956k

So I hit ^\ and it dumped core.  Here's what gdb said about the core:

Core was generated by `test'.
Program terminated with signal SIGQUIT, Quit.
#0  0xed9c9454 in __sanitizer::StaticSpinMutex::LockSlow (
    this=0xede968b8 <__sanitizer::report_file_mu>)
    at /usr/src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_mutex.cpp:24

warning: 24     /usr/src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_mutex.cpp: No such file or directory
(gdb) bt
#0  0xed9c9454 in __sanitizer::StaticSpinMutex::LockSlow (
    this=0xede968b8 <__sanitizer::report_file_mu>)
    at /usr/src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_mutex.cpp:24
#1  0xed9c72dc in __sanitizer::StaticSpinMutex::Lock (
    this=0xede968b8 <__sanitizer::report_file_mu>)
    at /usr/src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_mutex.h:32
#2  __sanitizer::GenericScopedLock<__sanitizer::StaticSpinMutex>::GenericScopedLock (mu=0xede968b8 <__sanitizer::report_file_mu>, this=<synthetic pointer>)
    at /usr/src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_mutex.h:367
    this=0xed9f4260 <__sanitizer::report_file>,
    buffer=0xefffedd8 "UndefinedBehaviorSanitizer: CHECK failed: sanitizer_mutex.h:42 \"((atomic_load(&state_, memory_order_relaxed))) == ((1))\" (0xff, 0x1) (tid=928)\n", length=143)
    at /usr/src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_posix.cpp:271

This bespoke spin lock built out of bespoke atomic operations in terms
of __sync_* compiler builtins has an internal state of 0xff instead of
1.  It turns out this sanitizer logic is simply misusing the
__sync_lock_test_and_set API to implement a C11-style atomic_exchange:
when you do __sync_lock_test_and_set(&lock, 1), it is not guaranteed to
set lock to 1; it is only guaranteed to set it to something nonzero.
On sparc, this value is 0xff, because that's what ou get from the
LDSTUB instruction.

Fortunately, I think we can just change this assertion:

  void CheckLocked() const CHECK_LOCKED() {
    CHECK_EQ(atomic_load(&state_, memory_order_relaxed), 1);
  }

to:

  void CheckLocked() const CHECK_LOCKED() {
    CHECK_NE(atomic_load(&state_, memory_order_relaxed), 0);
  }


State-Changed-From-To: analyzed->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 18 Apr 2025 23:32:28 +0000
State-Changed-Why:
fixed in HEAD, let's pull it up to 9 and 10 so we stop wasting so much
time on test runs for them too


From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53277 CVS commit: src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common
Date: Fri, 18 Apr 2025 23:30:27 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Fri Apr 18 23:30:27 UTC 2025

 Modified Files:
 	src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
 	    sanitizer_mutex.h

 Log Message:
 libubsan: Don't assume __sync_lock_test_and_set(&v, 1) sets v to 1.

 It may set v to some other nonzero value, as documented by gcc:

 > Many targets have only minimal support for such locks, and do not
 > support a full exchange operation.  In this case, a target may
 > support reduced functionality here by which the only valid value to
 > store is the immediate constant 1.  The exact value actually stored
 > in *ptr is implementation defined.

 https://gcc.gnu.org/onlinedocs/gcc-10.5.0/gcc/_005f_005fsync-Builtins.html

 (Actually, I'm not even sure it's guaranteed to be nonzero -- on hppa
 with LDCW (load and clear word), the obvious choice would be zero for
 locked and nonzero for locked.  But currently gcc doesn't take
 advantage of that on hppa.)

 With this, we will end our long tradition of having the releng sparc
 testbed spend several hours in every test run spinning to obtain a
 lock it already holds in order to report a `lock held' assertion
 failure that tripped because it assumed __sync_lock_test_and_set
 would store 1 and not 0xff -- a tradition we have carried on firmly
 for the last seven years (less a couple weeks) since these t_ubsan_*
 tests were first committed.

 PR port-sparc/53277: Many ubsan tests fail on sparc


 To generate a diff of this commit:
 cvs rdiff -u -r1.4 -r1.5 \
     src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_mutex.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search