Date: Tue, 20 Jul 2021 13:19:58 -0600 From: Christopher Hodgkins <George.Hodgkins@...orado.edu> To: musl@...ts.openwall.com Subject: Failing assertions in get_meta 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. Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.