From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [IPv6:2001:470:683e::1]) by sourceware.org (Postfix) with ESMTPS id 9901B3858D28 for ; Wed, 12 Apr 2023 17:26:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9901B3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1681320377; bh=+ti3ddyXAOTYHyVPInxXiRC1zEY8nzvxe9/Nr9V0dQ8=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Y/zKAMfXXuLeizlVUwr5EDxXzdtxApmgzVo4+5388M3YuImEpT+WJgg1YHEKHu2sq TgZ8oA2l6ezxenjtP/zWAbfhAUdeBQwWdswFb2zjV8U8r7oo94LAFjyhcecpxxdJKc wzwYHg9Ybk3UbLKM1piMl+c2ssSJztuGmkrJf/Xw= Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 63AE4663A7; Wed, 12 Apr 2023 13:26:17 -0400 (EDT) Message-ID: <701d23906ce7c22e4dff8f0e113c6196b63c0575.camel@xry111.site> Subject: Re: [PATCH v5 1/1] memalign: Support scanning for aligned chunks. From: Xi Ruoyao To: DJ Delorie Cc: libc-alpha@sourceware.org Date: Thu, 13 Apr 2023 01:26:15 +0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.0 MIME-Version: 1.0 X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 2023-04-12 at 13:16 -0400, DJ Delorie wrote: > Xi Ruoyao writes: > > On LoongArch (with a GCC 12.2 but LoongArch backend patched to match > > GCC > > trunk), this causes an almost deterministic failure of malloc/tst- > > malloc-thread-fail-malloc-hugetlb2: >=20 > (1) What's in malloc/tst-malloc-thread-fail-malloc-hugetlb2.out ? >=20 > (2) Have you tried with "export TIMEOUTFACTOR=3D20" ? some tests fail > =C2=A0=C2=A0=C2=A0 reliably on slower systems due to timeouts. No, it's not a timeout, but a segment fault. The output is just "error: exit status 139 from child process". I'm not an expert with ptmalloc, but there is some code like: arena_get (ar_ptr, bytes + alignment + MINSIZE); p =3D _int_memalign (ar_ptr, alignment, bytes); if (!p && ar_ptr !=3D NULL) { LIBC_PROBE (memory_memalign_retry, 2, bytes, alignment); ar_ptr =3D arena_get_retry (ar_ptr, bytes); p =3D _int_memalign (ar_ptr, alignment, bytes); } arena_get can set ar_ptr to NULL (at least when the system memory is not enough). Then _int_memalign is dereferencing ar_ptr w/o any nullity check (bin_at seems a "fancy" dereference operation to me). Then we test ar_ptr !=3D NULL in the if statement. Now it looks like a notorious "NULL check after dereferencing" pattern. So I added a nullity check: diff --git a/malloc/malloc.c b/malloc/malloc.c index 0315ac5d16..ed10b6b0e3 100644 --- a/malloc/malloc.c +++ b/malloc/malloc.c @@ -5025,7 +5025,7 @@ _int_memalign (mstate av, size_t alignment, size_t bytes) mchunkptr victim; =20 nb =3D checked_request2size (bytes); - if (nb =3D=3D 0) + if (nb =3D=3D 0 || !av) { __set_errno (ENOMEM); return NULL; And it indeed fixed the test for me. But I'm not sure if it's the correct solution and I've not ran the complete test suite with the change yet. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University