All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Peng Zhihong <zhihongx.peng@intel.com>
Cc: haiyue.wang@intel.com, qi.z.zhang@intel.com,
	beilei.xing@intel.com, dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC] mem_debug add more log
Date: Fri, 18 Dec 2020 10:54:24 -0800	[thread overview]
Message-ID: <20201218105424.6731d866@hermes.local> (raw)
In-Reply-To: <20201218192109.50098-1-zhihongx.peng@intel.com>

On Fri, 18 Dec 2020 14:21:09 -0500
Peng Zhihong <zhihongx.peng@intel.com> wrote:

> 1. The debugging log in current DPDK RTE_MALLOC_DEBUG mode is insufficient,
>    which makes it difficult to locate the issues, such as:
>    a) When a memeory overlflow occur in rte_free, there is a little log
>       information. Even if abort here, we can find which API is core
>       dumped but we still need to read the source code to find out where
>       the requested memory is overflowed.
>    b) Current DPDK can NOT find that the overflow if the memory has been
>       used and not released.
>    c) If there are two pieces of continuous memory, when the first block
>       is not released and an overflow is occured and also the second block
>       of memory is covered, a memory overflow will be detected once the second
>       block of memory is released. However, current DPDK can not find the
>       correct point of memory overflow. It only detect the memory overflow
>       of the second block but should dedect the one of first block.
>       ----------------------------------------------------------------------------------
>       | header cookie | data1 | trailer cookie | header cookie | data2 |trailer cookie |
>       ----------------------------------------------------------------------------------
> 2. To fix above issues, we can store the requested information When DPDK
>    request memory. Including the requested address and requested momory's
>    file, function and numbers of rows and then put it into a list.
>    --------------------     ----------------------     ----------------------
>    | struct list_head |---->| struct malloc_info |---->| struct malloc_info |
>    --------------------     ----------------------     ----------------------
>    The above 3 problems can be solved through this implementation:
>    a) If there is a memory overflow in rte_free, you can traverse the
>       list to find the information of overflow memory and print the
>       overflow memory information. like this:
>       code:
>       37         char *p = rte_zmalloc(NULL, 64, 0);
>       38         memset(p, 0, 65);
>       39         rte_free(p);
>       40         //rte_malloc_validate_all_memory();
>       memory error:
>       EAL: Error: Invalid memory
>       malloc memory address 0x17ff2c340 overflow in \
>       file:../examples/helloworld/main.c function:main line:37
>    b)c) Provide a interface to check all memory overflow in function
>       rte_malloc_validate_all_memory, this function will check all
>       memory on the list. Call this funcation manually at the exit
>       point of business logic, we can find all overflow points in time.
> 
> Signed-off-by: Peng Zhihong <zhihongx.peng@intel.com>

Good concept, but doesn't this add significant overhead?

Maybe we could make rte_malloc work with existing address sanitizer infrastructure
in gcc/clang?  That would provide faster and more immediate better diagnostic
info.

  reply	other threads:[~2020-12-18 18:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-18 19:21 [dpdk-dev] [RFC] mem_debug add more log Peng Zhihong
2020-12-18 18:54 ` Stephen Hemminger [this message]
2020-12-21  7:35   ` Peng, ZhihongX
2020-12-21 18:44     ` Stephen Hemminger
2020-12-25  7:20       ` Peng, ZhihongX
2023-06-12  2:17         ` Stephen Hemminger

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=20201218105424.6731d866@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=haiyue.wang@intel.com \
    --cc=qi.z.zhang@intel.com \
    --cc=zhihongx.peng@intel.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.