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.3 required=5.0 tests=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 16153 invoked from network); 20 Jul 2021 23:40:43 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Jul 2021 23:40:43 -0000 Received: (qmail 11387 invoked by uid 550); 20 Jul 2021 23:40:41 -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 11363 invoked from network); 20 Jul 2021 23:40:40 -0000 Date: Tue, 20 Jul 2021 19:40:28 -0400 From: Rich Felker To: Christopher Hodgkins Cc: musl@lists.openwall.com Message-ID: <20210720234026.GL13220@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Failing assertions in get_meta On Tue, Jul 20, 2021 at 01:19:58PM -0600, Christopher Hodgkins wrote: > 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(), If this assertion fails, it means that the group header's pointer to the out-of-band metadata is either pointing to the wrong place (e.g. because it was overwritten by some out-of-bounds access to allocated memory) or points to the correct metadata location but the structure at the location has been overwritten. > 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? Perhaps, if you're not following the semantics of mmap (that it yield page-aligned, page-granular memory) or not honoring the obligation to faithfully store data written to the memory. Without knowing the specifics of your modification it's hard to say. > 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? No. > 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. You could try disabling brk entirely by making it never return a value equal to its argument, as in: #define brk(p) ((p)-1) This would help determine if your problem is caused by your brk or something else. Rich