git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Jeffrey Walton <noloader@gmail.com>
Cc: Todd Zullinger <tmz@pobox.com>, Git List <git@vger.kernel.org>
Subject: Re: One failed self test on Fedora 29
Date: Sun, 10 Mar 2019 23:29:24 -0400	[thread overview]
Message-ID: <20190311032923.GA7087@sigill.intra.peff.net> (raw)
In-Reply-To: <CAH8yC8mg3vjPoof5SDemQ_YiL+7e1ak535U2nFnPbaWJ8xSWOA@mail.gmail.com>

On Sat, Mar 09, 2019 at 07:34:15AM -0500, Jeffrey Walton wrote:

> > It would probably help to know what commit you're building.
> > The verbose test output would also be useful, e.g.:
> 
> I built with CFLAGS += -fsanitize=undefined. It looks like the
> misaligned accesses generate UBsan findings, which is causing
> t0021-conversion to fail.

You probably should use SANITIZE=undefined instead. The Makefile has
some smarts to tweak build parameters based on your sanitize flag (e.g.,
defining NO_UNALIGNED_LOADS).

That said, I do not think sha1dc works with UBsan at this point at all.
I usually do error-checking builds with:

  make SANITIZE=address,undefined BLK_SHA1=Yes

What puzzles me is not that t0021 failed, but that everything else
_didn't_. Almost every script fails for me when Git is built with UBSan
and sha1dc.

It would be nice to make sha1dc respect NO_UNALIGNED_LOADS. But barring
that, we should probably default to BLK_SHA1 when we see
SANITIZE=undefined.

-Peff

      parent reply	other threads:[~2019-03-11  3:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-08 10:48 One failed self test on Fedora 29 Jeffrey Walton
2019-03-08 17:43 ` Todd Zullinger
2019-03-09 12:34   ` Jeffrey Walton
2019-03-09 13:12     ` Jeffrey Walton
2019-03-11  2:00       ` Junio C Hamano
2019-03-11  2:16         ` Jeffrey Walton
2019-03-11  3:37         ` disabling sha1dc unaligned access, was " Jeff King
2019-03-11 10:40           ` Jeffrey Walton
2019-03-11 18:19             ` Jeff King
2019-03-11 11:58           ` Duy Nguyen
2019-03-11 18:15             ` Thomas Braun
2019-03-11 18:23               ` Jeff King
2019-03-12  7:27                 ` Junio C Hamano
2019-03-12 10:51                   ` Jeff King
2019-03-13 11:47                     ` Thomas Braun
2019-03-13 15:39                       ` Jeff King
2019-03-13 16:00                         ` Ævar Arnfjörð Bjarmason
2019-03-12  8:53                 ` Ævar Arnfjörð Bjarmason
2019-03-12 11:05                   ` Jeff King
2019-03-12 12:09                     ` Ævar Arnfjörð Bjarmason
2019-03-12 21:01                       ` Jeff King
2019-03-12 21:06           ` [PATCH] Makefile: fix unaligned loads in sha1dc with UBSan Jeff King
2019-03-12 21:17             ` Ævar Arnfjörð Bjarmason
2019-03-12 21:19               ` Jeff King
2019-03-11  3:29     ` Jeff King [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190311032923.GA7087@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=noloader@gmail.com \
    --cc=tmz@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).