From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 94F221F506 for ; Thu, 22 Sep 2022 10:05:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229787AbiIVKEp (ORCPT ); Thu, 22 Sep 2022 06:04:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231251AbiIVKEk (ORCPT ); Thu, 22 Sep 2022 06:04:40 -0400 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C39C63F2 for ; Thu, 22 Sep 2022 03:04:38 -0700 (PDT) Received: (qmail 5631 invoked by uid 109); 22 Sep 2022 10:04:37 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Thu, 22 Sep 2022 10:04:37 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 902 invoked by uid 111); 22 Sep 2022 10:04:40 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Thu, 22 Sep 2022 06:04:40 -0400 Authentication-Results: peff.net; auth=none Date: Thu, 22 Sep 2022 06:04:37 -0400 From: Jeff King To: git@vger.kernel.org Cc: Victoria Dye Subject: t9210-scalar.sh fails with SANITIZE=undefined Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Running t9210 with the tip of master triggers a problem with UBSan: $ make SANITIZE=undefined [...] $ cd t $ ./t9210-scalar.sh -v -i [...] read-cache.c:1886:46: runtime error: member access within misaligned address 0x7f7c09bf7055 for type 'struct ondisk_cache_entry', which requires 4 byte alignment 0x7f7c09bf7055: note: pointer points here 33 2e 74 00 63 2c 31 42 17 3f 49 72 63 2c 31 42 17 3f 49 72 00 00 fe 01 02 60 06 4d 00 00 81 a4 ^ Now here's the interesting part. We do carefully read most of the data out of the struct with get_be16(), which should handle alignment (we have to do so because that on_disk_cache_entry is literally just a cast from an mmap'd buffer). But the line in question is just: const uint16_t *flagsp = (const uint16_t *)(ondisk->data + hashsz); It's not even reading anything, but just computing an offset within the struct. I don't think that line in particular is to blame. If I use an older version of Git that predates it on the same repo generated by t9210, I get a similar error for a different line. Another thing to note is that the command which fails isn't scalar itself! It's just vanilla "git add -- loose.t". But it's curious that we never saw this alignment problem before. I wonder if the scalar-cloned repository has some index options turned on that trigger the issue. I didn't dig further. It's obviously new in v2.38.0-rc1, but I'm not sure it's a show-stopper. It _might_ have been there all along, and is just now surfacing. Or it might be in an existing experimental feature that just wasn't exercised enough in the tests. Or if it really is new in scalar, then it will only hurt people using scalar, which didn't exist before. So I don't think it's a regression in the strictest sense, but it might be nice to get a more accurate understanding of the problem before the release. -Peff