Re: DPDK (and rte_*alloc family) friendly Valgrind

[Luca Boccassi <lboccass@Brocade.com>]

On Fri, 2016-02-12 at 22:47 -0800, Matthew Hall wrote:
> 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:
> 
> ==18730== Source and destination overlap in memcpy(0x6851c00, 0x6851c00, 4144)
> ==18730==    at 0x4C30573: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==18730==    by 0x787195: sort_by_physaddr (eal_memory.c:747)
> ==18730==    by 0x788314: rte_eal_hugepage_init (eal_memory.c:1198)
> ==18730==    by 0x8F1888: rte_eal_memory_init (eal_common_memory.c:145)
> ==18730==    by 0x751BB6: rte_eal_init (eal.c:793)
> ==18730==    by 0x4D9E8A: main (sdn_sensor.c:555)
> 
> ==18730== Thread 3:
> ==18730== Syscall param epoll_ctl(event) points to uninitialised byte(s)
> ==18730==    at 0x60C249A: epoll_ctl (syscall-template.S:81)
> ==18730==    by 0x72F88E: eal_intr_thread_main (eal_interrupts.c:844)
> ==18730==    by 0x581A6A9: start_thread (pthread_create.c:333)
> ==18730==    by 0x60C1EEC: clone (clone.S:109)
> ==18730==  Address 0x8400b38 is on thread 3's stack
> ==18730==  in frame #1, created by eal_intr_thread_main (eal_interrupts.c:801)
> ==18730==
> 
> I'll be running my app with this special valgrind heavily and patching these from now on.

Hi Matthew,

Very cool, happy to help :-)

Unrelated to Valgrind but related to debugging tools: I've been playing
with our DPDK application and GCC's address sanitizer, and I would
recommend looking into it. It cannot be turned on in production as it
kills performance, but for test builds it's very useful as it will abort
when out-of-bounds reads/writes or use-after-free happen. To use it
simply add -fsanitize=address to the CFLAGS.

> 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...

Sure thing, good idea! I've pushed an "upstream" branch on the commit
that did the initial import. This way we can follow the common workflow
of importing upstream changes into their own branch, and then merging
into the master branch, which has the patches. Does that sound
reasonable?

-- 
Kind regards,
Luca Boccassi
Brocade Communications Systems