public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Sean Anderson <seanga2@gmail.com>
Cc: u-boot@lists.denx.de, Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Simon Glass <sjg@chromium.org>
Subject: Re: [PATCH v3 2/3] malloc: Annotate allocator for valgrind
Date: Mon, 11 Apr 2022 10:17:25 -0400	[thread overview]
Message-ID: <20220411141725.GC14282@bill-the-cat> (raw)
In-Reply-To: <20220323180451.48950-3-seanga2@gmail.com>

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

On Wed, Mar 23, 2022 at 02:04:49PM -0400, Sean Anderson wrote:

> This annotates malloc and friends so that valgrind can track the heap. To
> do this, we need to follow a few rules:
> 
> * Call VALGRIND_MALLOCLIKE_BLOCK whenever we malloc something
> * Call VALGRIND_FREELIKE_BLOCK whenever we free something (generally after
>   we have done our bookkeeping)
> * Call VALGRIND_RESIZEINPLACE_BLOCK whenever we change the size of an
>   allocation. We don't record the original request size of a block, and
>   neither does valgrind. For this reason, we pretend that the old size of
>   the allocation was for 0 bytes. This marks the whole allocaton as
>   undefined, so in order to mark all bits correctly, we must make the whole
>   new allocation defined with VALGRIND_MAKE_MEM_DEFINED. This may cause us
>   to miss some invalid reads, but there is no way to detect these without
>   recording the original size of the allocation.
> 
> In addition to the above, dlmalloc itself tends to make a lot of accesses
> which we know are safe, but which would be unsafe outside of dlmalloc. For
> this reason, we provide a suppression file which ignores errors ocurring in
> dlmalloc.c
> 
> Signed-off-by: Sean Anderson <seanga2@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2022-04-11 14:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-23 18:04 [PATCH v3 0/3] malloc: Enable profiling dlmalloc with valgrind Sean Anderson
2022-03-23 18:04 ` [PATCH v3 1/3] Add valgrind headers to U-Boot Sean Anderson
2022-04-11 14:17   ` Tom Rini
2022-03-23 18:04 ` [PATCH v3 2/3] malloc: Annotate allocator for valgrind Sean Anderson
2022-04-11 14:17   ` Tom Rini [this message]
2022-03-23 18:04 ` [PATCH v3 3/3] doc: sandbox: Document how to run sandbox with valgrind Sean Anderson
2022-04-11 14:17   ` Tom Rini
2022-03-30 18:13 ` [PATCH v3 0/3] malloc: Enable profiling dlmalloc " Sean Anderson

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=20220411141725.GC14282@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=seanga2@gmail.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox