From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E9DADA09FD; Fri, 18 Dec 2020 19:54:55 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2EC50CABE; Fri, 18 Dec 2020 19:54:54 +0100 (CET) Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by dpdk.org (Postfix) with ESMTP id C44DACAB2 for ; Fri, 18 Dec 2020 19:54:51 +0100 (CET) Received: by mail-pl1-f175.google.com with SMTP id y8so1862945plp.8 for ; Fri, 18 Dec 2020 10:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=HgTeM2kXZ5kUE8uEIXF8CSbvr9q++iLanXdVwppSbaw=; b=XySe1064exH78HI8Savjc4GIJ1t3/OwAoITwkG7nIusIB/KCf4C5mgDi7WfIALSMMb uxIYfE+3vYMJ9zPF1C8fxLWJGdVWtcRwd+eLUIwjWiLtc02uagd1tzCKGi0GbyZPtEMy jBFFBpNI4dOV9QHoGxa5L+8M347iENYLK4RUDsPNOOf73kpTQNAJnT5qEPjwO29zLVyE R4DuAD6gAnz0DggcWVlxqYysBWbHWyQ4vCKGyvTcqrow7lrKIRUz4DYn/bu10BVbAPL5 z1sxoEOeHucjVlbeoJKoCEMUxR5QJUW2Q17IuBqu90RSDKUSMjZo5HNp9Nm0jPj+X69r C6kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=HgTeM2kXZ5kUE8uEIXF8CSbvr9q++iLanXdVwppSbaw=; b=IFdZCjNAew8SxjlzWLYqHXI19Pfms7b+2FQXYKXEnEUto8+xJ/ZMWxvljEruklI025 MUIatXYnSAAfLb9kSuQuZVaWTG5B8gYWdwDGo1TGH2mAqP+8V78T2jzfQUL2FguYo4Wx ahVZZp2L3PrnVjvp+X6ysyYpWJC9qTF4d8Gomd/vmGZwjXHGOCiKhL+QstnVdWrZnpr7 NYFGhFRZnNZY+Z4vr/vh5251RdF4MXu6NuZaHMZx1Sj7l6PqiQlMlbX34TLQ5KqoKxiq y5fLLt8YRLwQD/u6N2Dcg4h12uT4hG15va+cE5AcrWFt55R0COJIBb7ZmGzKFsseDU7C C5+g== X-Gm-Message-State: AOAM531nDKW/YpZjeZN44VApVb5ug6LJ3c/JI0bp165RLQHg0zFIGlVm hVj5O1Rq9DAt6pTpqLnVL27g5g== X-Google-Smtp-Source: ABdhPJxthway7xUQksobABzweHrwTHj20g5AKcwPH/ZzLn4IHtBIINY/pO0cxScsRYVPWp6Fdhk5/Q== X-Received: by 2002:a17:902:c195:b029:db:c725:2522 with SMTP id d21-20020a170902c195b02900dbc7252522mr5765647pld.83.1608317689849; Fri, 18 Dec 2020 10:54:49 -0800 (PST) Received: from hermes.local (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id l7sm8146583pjy.29.2020.12.18.10.54.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Dec 2020 10:54:49 -0800 (PST) Date: Fri, 18 Dec 2020 10:54:24 -0800 From: Stephen Hemminger To: Peng Zhihong Cc: haiyue.wang@intel.com, qi.z.zhang@intel.com, beilei.xing@intel.com, dev@dpdk.org Message-ID: <20201218105424.6731d866@hermes.local> In-Reply-To: <20201218192109.50098-1-zhihongx.peng@intel.com> References: <20201218192109.50098-1-zhihongx.peng@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC] mem_debug add more log X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, 18 Dec 2020 14:21:09 -0500 Peng Zhihong 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 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.