On 2020-06-01 18:17, Stephen Hemminger wrote:
On Mon, 01 Jun 2020 15:24:25 +0200 Alex Kiselev <[email protected]> wrote:Hello, I've got a segmentation fault error in my data plane path. I am pretty sure the code where the segfault happened is ok, so my guess is that I somehow received a corrupted mbuf. How could I troubleshoot this? Is there any way? Is it possible that other threads of the application corrupted that mbuf? I would really appriciate any advice. Thanks. DPDK 18.11.3 NIC: 82599ES Code: nb_rx = rte_eth_rx_burst(port_id, queue_id, pkts_burst, MAX_PKT_BURST); ... for (i=0; i < vec_size; i++) { rte_prefetch0(rte_pktmbuf_mtod(m_v[i], void *)); for (i=0; i < vec_size; i++) { m = m_v[i]; eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *); eth_type = rte_be_to_cpu_16(eth_hdr->ether_type); <--- Segmentation fault ... #0 rte_arch_bswap16 (_x=<error reading variable: Cannot access memory at address 0x4d80000000053010>)Build with as many of the debug options turned on in the DPDK config, and build with EXTRA_CFLAGS of -g.
I usually use this options in some debug environments: CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=y CONFIG_RTE_MALLOC_DEBUG=y as well as gcc sanitize options and some custom memory sanitize techniques to make sure there is no mempool leaks, use after free or double free. But what was your point? Could you please explain what should I expect from enabling other debug options or what should I pay attention to? Should I take a look the PMD drivers debug options? Unfortunately, there is no way to reproduce the bug. So I need to understand what could cause it to make my search more precise.
