mailing list of musl libc
 help / color / mirror / Atom feed
From: Christopher Hodgkins <George.Hodgkins@colorado.edu>
To: musl@lists.openwall.com
Subject: [musl] Failing assertions in get_meta
Date: Tue, 20 Jul 2021 13:19:58 -0600
Message-ID: <CAGd_VJy7DCcG+RN-yAeZzNcChZ7AJnjKNLm+AXT-wNT56=21Yw@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2008 bytes --]

             reply	other threads:[~2021-07-20 19:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-20 19:19 Christopher Hodgkins [this message]
2021-07-20 23:40 ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGd_VJy7DCcG+RN-yAeZzNcChZ7AJnjKNLm+AXT-wNT56=21Yw@mail.gmail.com' \
    --to=george.hodgkins@colorado.edu \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ https://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git