From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12511 invoked from network); 25 Jan 2023 06:49:07 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 25 Jan 2023 06:49:07 -0000 Received: (qmail 21802 invoked by uid 550); 25 Jan 2023 06:49:05 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 21761 invoked from network); 25 Jan 2023 06:49:03 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=e53qteMjor/7XEqRT6JCGfZnkMHc2lb/rcKfL/k/SAM=; b=kK02ckEuJZjwzD7NWJL4ykbyu0EVmgZ57G36IlfIDuQ+ElAkQ7nWEFlAGlCxLSQs+P TM8x1t6hIf0Nb/Sy5ezbtJ1SvhF4TpnBQdpNLM0m/qB3XIReDNjMCpUE6XBVf38JLtFq Vk79gaO7kX9BNDY+EK+bf3Kdd0jL3d9gWTEXa5sg7aPUFWiogC8AHVm4FCLkp2Fo4TVS jKhAs/aJgeTEkuYSQsM5CSWF0JBEEtVoKXQubOwdzXCJ3zGNBfXYxovBhBsV9eYMlgzH /iiAHXy0vunGX/fpSwZA8uQjIIPJLVGcrrlAI6x0UZfEWHTs6rS8eRXzCQ0lsdM7Dq7j tPgQ== X-Gm-Message-State: AFqh2kr9OOzUpL4ngRFNp6GZdjGtuChAc//kcFUNdB81DCn2roIT2pV5 Reb858m4b6gid2Cs2Tc9O16PNrZFu1ob0mAmwjAGU5KEEO3FVXydYdzf46kkm8MXar12i609pRf mrkLnGPOBGv0mLxFyTU7xOg== X-Received: by 2002:a62:1884:0:b0:58b:c7f8:623c with SMTP id 126-20020a621884000000b0058bc7f8623cmr26390341pfy.27.1674629329873; Tue, 24 Jan 2023 22:48:49 -0800 (PST) X-Google-Smtp-Source: AMrXdXsQNbRq3PJTinzpChssU2Yu8CtgqqMy11zykW8Vj3WNMuv1YNuk4ATlixylzVmX3f6WDSEuHA== X-Received: by 2002:a62:1884:0:b0:58b:c7f8:623c with SMTP id 126-20020a621884000000b0058bc7f8623cmr26390325pfy.27.1674629329387; Tue, 24 Jan 2023 22:48:49 -0800 (PST) Date: Wed, 25 Jan 2023 15:48:37 +0900 From: Dominique MARTINET To: Rich Felker Cc: musl@lists.openwall.com Message-ID: References: <20230124083747.GI4163@brightrain.aerifal.cx> <20230125055323.GK4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230125055323.GK4163@brightrain.aerifal.cx> Subject: Re: [musl] infinite loop in mallocng's try_avail Rich Felker wrote on Wed, Jan 25, 2023 at 12:53:23AM -0500: > > > This is really weird, because at the point of the infinite loop, the > > > new group should not yet be activated (line 163), so > > > __malloc_context->active[0] should still point to the old active > > > group. But its avail_mask has all bits set and active_idx is not > > > corrupted, so try_avail should just have obtained an available slot > > > from it without ever entering the block at line 120. So I'm confused > > > how it got to the loop. > > > > try_avail's pm is `__malloc_context->active[0]`, which is overwritten by > > either dequeue(pm, m) or *pm = m (lines 123,128), so the original > > m->avail_mask could have been zero, with the next element having a zero > > freed mask? > > No, avail_mask is only supposed to be able to be nonzero after > activate_group, which is only called on the head of an active list > (free.c:86 or malloc.c:163) and which atomically pulls bits off > freed_mask to move them to avail_mask. If we're observing avail_mask > nonzero at the point you saw it, some invariant seems to have been > violated. Ok, so if I understood that correctly, the second item in the list should not have avail_mask set, so it having a non-zero value after we poped the first element is unexpected? The avail_mask value is 1073741822, which from a naive interpretation looks a lot like it got through alloc_group (2<<29 -1), 29 being its last_idx which match up with active_idx (line 272 and 280), then perhaps alloc_slot (avail_mask--) to make up for that extra -1... But that does not explain how it got in second place in the active list, and guessing in a code base I haven't even fully read will only get so far. Alright, it does not look like we can use more informations from the currently pending process, I will try to get more traces. I'll add a circular buffer to log things like the active[0] at entry and its mask values, then set my board up to reproduce again, which will probably bring us to next Monday. If there is anything else you'd like to see, please ask. -- Dominique Martinet