From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id ED0A43858C36; Tue, 26 Mar 2024 13:39:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ED0A43858C36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1711460354; bh=S22qxsRY0tJ9iDki5HAasF8rB6COb7ZEnQomKciCUuw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eD8iBH6aI8FjwBqAc9hgPkYZT/1LoYWYw8so8NB3YnxQf5xAtAExy4PUAZ/k7OEd6 ecN5JZ315Q/TAXPn3/x3FG3uZlwIbqsPbcEP4tH1s7lGRa3m0WxxGiz5il/HfyRmiW cRyhylB3Fvuh5Yq2FsLCofS4asW2kfXKd04kC5z4= From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug malloc/31553] elf/tst-decorate-maps fails on ppc64el Date: Tue, 26 Mar 2024 13:39:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: malloc X-Bugzilla-Version: 2.39 X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31553 Adhemerval Zanella changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adhemerval.zanella at lina= ro dot o | |rg --- Comment #4 from Adhemerval Zanella --- (In reply to Simon Chopin from comment #3) > Thanks Andreas for pointing me to the page size. >=20 > There's an assumption made in the test that the early allocation code will > need to grow beyond the initial data page, as those extra pages would be = the > ones marked "[anon: glibc: loader malloc]". However, if the page size is > large enough, I guess that assumption isn't valid anymore. >=20 > I'll write a patch skipping this particular assertion if the page size is > 64k or above. I could reproduce it on a ppc64le VM, and it seems to what you described: t= he __minimal_malloc never issues the mmap because the initial data segment can supply the loader memory requirement. I think without a way to trigger the load mmap allocation, it would be better to just remove the 'loader malloc' check (it might be that we will need to adjust for possible different page sizes). --=20 You are receiving this mail because: You are on the CC list for the bug.=