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=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17800 invoked from network); 20 Jul 2021 19:22:06 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Jul 2021 19:22:06 -0000 Received: (qmail 1647 invoked by uid 550); 20 Jul 2021 19:21:59 -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 32570 invoked from network); 20 Jul 2021 19:20:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colorado.edu; s=google; h=mime-version:reply-to:from:date:message-id:subject:to; bh=VNMHepTJE9rT3ofBhgyXWOVBU58ZqzMga8J/gkXrjA4=; b=WQkpDgEt/YaYwr6sCapP5wJvmBDioo+keqBFL6TcTfsnONz6i7OObz6fjIdIQ0x9jf UIC2rmmd3OS7eC97VvfZjezD35+yMyj04OyXmP06ee/syNixAEuB4erYrHkaXoy3LjsB UjXpk/vgH6Xr7eBZxxWFvlEadw9NRyRBGqESO8uN/d0h3ewH/NXdAf6iGJR1jk9NM39a UBmnLvlcJnJD+v6eXjb18mPc5f43/BD0t86bFAWLsnargrS/fQujYsGB0tKgUCSFlk+4 ThtS2oC6qEFLNzgpG904faAD5LwmEqrYs9gv/Z230LI++Q1g6eipqfXoHi/IA4DZoWuC CWmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=VNMHepTJE9rT3ofBhgyXWOVBU58ZqzMga8J/gkXrjA4=; b=suOCLYKQHFCCBczl9IeUAxsbxDkjMxxBwXZ855F7Jk3VpxMZZOMM4RSLytNI/Z98SV LQRWN20CSHnMlrTh9HomvqHP09928F0VMsWF4Xikxxl2MPjQoIYHJXP9ogQE73ZeSi7r waD4HBLurzl98Nxg6Ai1d6iIl/f7h+Z3KJ1zw4wt02LfrIU5VHz4wUjCSB11UFaJOXVt V/sN1LCV1SNm2X+hYiHkVjhusGpx8g8EHuG97pmtw1z2TXZWhYCnPrtqbUbT0No2Svnw AM53f8+dmS7lBPs92K0ZZiGu/S8HS3cS9CqETesBK3HRLc+/3bKlDwSDFNSW0lIGYUsB 66Bg== X-Gm-Message-State: AOAM530NvKNdLor1BVdEbLKI7YOmLBMoTPDeR6jj4T6EFnliEsQ+IwQS qWeS7DquIdoJygWy7f0xFoQkQrD8QLVrYSpOfY3m8KRydaZfUQ== X-Google-Smtp-Source: ABdhPJwa/SM4VX0cBynXfRsEV60d4QsCF9ZBY/KMeJhj0GG4nT0QSlsiAfygB7aFeZgWGno8PbglL0YGFbmH/FY0s/Y= X-Received: by 2002:a2e:a36d:: with SMTP id i13mr9552559ljn.510.1626808804944; Tue, 20 Jul 2021 12:20:04 -0700 (PDT) MIME-Version: 1.0 From: Christopher Hodgkins Date: Tue, 20 Jul 2021 13:19:58 -0600 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000efc3ee05c792f0db" Subject: [musl] Failing assertions in get_meta --000000000000efc3ee05c792f0db Content-Type: text/plain; charset="UTF-8" Hi all, I'm working on a modified version of musl for some research. We replaced the typical memory provisioning methods (mmap/brk) with our own versions which change the backing of the provided memory, but maintain the same semantics from the perspective of the caller, except that the program break is no longer adjacent to the rest of the mapped binary. We have been encountering various failed assertions in mallocng during debugging in the get_meta function. Specifically, we see the assertion at line 141 in meta.h (meta == mem->base) failing when free()-ing memory previously allocated with malloc(), and the assertion at line 131 ( !((uintptr_t)p & 15) ) failing for calls to posix_memalign with an alignment of 16 and a length of 704. Could our changes in the backing of provisioned memory cause this? Related question: We are aware of (and have disabled) the "donation" functionality in the loader. Are there other out-of-band (i.e. not mmap/sbrk) sources of memory used by mallocng? The errors are caused in some way by our changes, but we haven't changed anything inside the allocator, except to point the brk() macro to our own implementation rather than the syscall. So I assume there must be either some memory getting used that we don't know about, or some error in our implementation. Thanks for your assistance, George Build info: Working from commit 1f0c7cb1cc2170bf230623dc0b57d9a9f001af08 on master (HEAD at time of writing). Installed at /usr in a Docker container running Alpine Linux 3.14 on x86_64. Musl was compiled with --enable-debug and -O0. Our test programs are compiled with normal gcc inside the container after installing musl. --000000000000efc3ee05c792f0db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
I'm working on a modified version of musl = for some research.
We replaced the typical memory provisioning me= thods (mmap/brk)
with our own versions which change the backing o= f the provided memory,
but maintain the same semantics from the p= erspective of the caller,
except that the=C2=A0program break is n= o longer adjacent to the=C2=A0rest of the mapped binary.=C2=A0
We have been encountering various failed=C2=A0assertions in ma= llocng during debugging
in the get_meta function. Specifically, w= e see the assertion at line 141 in meta.h (meta =3D=3D mem->base)
<= div>failing when free()-ing memory previously allocated with malloc(),
and the assertion at line 131 ( !((uintptr_t)p & 15) ) failing fo= r calls to posix_memalign
with an alignment of 16 and a length of= 704. Could our changes in the backing of provisioned memory cause this?

Related question: We are aware of (and have disabled= ) the "donation" functionality in the loader.
Are there= other out-of-band (i.e. not mmap/sbrk) sources of memory used by mallocng?=
The errors are caused in some way by our changes, but we haven&#= 39;t changed anything inside the allocator,
except to point the b= rk() macro to our own implementation rather than the syscall.
So = I assume there must be either some memory getting used that we don't kn= ow about,
or some error in our implementation.

Thanks for your assistance,
George

Build info:
Working from commit 1f0c7cb1cc2170bf230623dc0b57d9a= 9f001af08 on master (HEAD at time of writing).
Installed at /usr = in a Docker container running Alpine Linux 3.14 on x86_64.
Musl w= as compiled with --enable-debug and -O0. Our test programs are compiled wit= h normal gcc inside the
container after installing musl.
--000000000000efc3ee05c792f0db--