From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mhall@mhcomputing.net>
Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170])
 by dpdk.org (Postfix) with ESMTP id C94CA918F
 for <dev@dpdk.org>; Sat, 13 Feb 2016 07:47:49 +0100 (CET)
Received: from [192.168.1.77] (99-34-229-174.lightspeed.sntcca.sbcglobal.net
 [99.34.229.174])
 by mail.mhcomputing.net (Postfix) with ESMTPSA id 08851121;
 Fri, 12 Feb 2016 22:47:48 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Matthew Hall <mhall@mhcomputing.net>
In-Reply-To: <1719358.h1p3ccrXDn@xps13>
Date: Fri, 12 Feb 2016 22:47:47 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <33FC4BA3-61EA-4681-AF73-E5C38002B3D3@mhcomputing.net>
References: <1455144896.2805.32.camel@brocade.com> <1719358.h1p3ccrXDn@xps13>
To: Luca Boccassi <lboccass@brocade.com>
X-Mailer: Apple Mail (2.3112)
Cc: "<dev@dpdk.org>" <dev@dpdk.org>
Subject: Re: [dpdk-dev] DPDK (and rte_*alloc family) friendly Valgrind
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Feb 2016 06:47:50 -0000

2016-02-10 22:54, Luca Boccassi:
> I created a set of patches for Valgrind that add support for the =
rte_*alloc family of functions. We use it for memcheck

Hi Luca,

This is awesome stuff:

=3D=3D18730=3D=3D Source and destination overlap in memcpy(0x6851c00, =
0x6851c00, 4144)
=3D=3D18730=3D=3D    at 0x4C30573: memcpy@@GLIBC_2.14 (in =
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
=3D=3D18730=3D=3D    by 0x787195: sort_by_physaddr (eal_memory.c:747)
=3D=3D18730=3D=3D    by 0x788314: rte_eal_hugepage_init =
(eal_memory.c:1198)
=3D=3D18730=3D=3D    by 0x8F1888: rte_eal_memory_init =
(eal_common_memory.c:145)
=3D=3D18730=3D=3D    by 0x751BB6: rte_eal_init (eal.c:793)
=3D=3D18730=3D=3D    by 0x4D9E8A: main (sdn_sensor.c:555)

=3D=3D18730=3D=3D Thread 3:
=3D=3D18730=3D=3D Syscall param epoll_ctl(event) points to uninitialised =
byte(s)
=3D=3D18730=3D=3D    at 0x60C249A: epoll_ctl (syscall-template.S:81)
=3D=3D18730=3D=3D    by 0x72F88E: eal_intr_thread_main =
(eal_interrupts.c:844)
=3D=3D18730=3D=3D    by 0x581A6A9: start_thread (pthread_create.c:333)
=3D=3D18730=3D=3D    by 0x60C1EEC: clone (clone.S:109)
=3D=3D18730=3D=3D  Address 0x8400b38 is on thread 3's stack
=3D=3D18730=3D=3D  in frame #1, created by eal_intr_thread_main =
(eal_interrupts.c:801)
=3D=3D18730=3D=3D

I'll be running my app with this special valgrind heavily and patching =
these from now on.

I was wondering, is there a way to get the patchset on its own branch =
versus the master valgrind in your repository? If so it will be easier =
for the rest of the community to assist you with rebasing it =
periodically to the upstream valgrind. This would be easy if you keep =
their upstream code in one branch and the patches applied in another =
branch. Then we can update the master one somehow and rebase the patched =
one to this new code...

Matthew.=