From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by dpdk.org (Postfix) with ESMTP id C6EFE5917 for ; Mon, 17 Mar 2014 20:44:17 +0100 (CET) Received: by mail-qa0-f49.google.com with SMTP id j7so5798248qaq.36 for ; Mon, 17 Mar 2014 12:45:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=olyhDGHvoWLF8/LmHq/WAtl8bMszOAK11bHTimf/+5s=; b=DCbbU4O5K5HIVYsuhwdpuFDqoi45uwcurfFucnzEu9PcfQqfS0iCvhbSB+B+h/6yjX Imh4pMNlBQMX/6skuCCf91v54m8C5BHEhKP8VO9nN0FylxNxdMY+aiVohq/EQHLqn9LM CkBCmaoi9EpzmqGttXvc3Z5GKGrHvbjbWN7N8jkHdUstJ9vYkzXsj8yFaxatEgF+9nEU zNfhhdMgxmCvFTo1YdJXya2yishPRirI8POkItrqFyUftRNUmf/pQLeHxtnmd2CgX0VR YCZjNyjf2vp8O2BfQ5hSe18VJXjHFHQsqwW6iBGrv8nrddpgsBk4s7Dk+IareD7m8DSN B8yQ== X-Gm-Message-State: ALoCoQlc0gDajqi/06x3vodIpD3DRX4ZWlbFCMkzG/c8tjnDHrJkG83e2ixbusvlOQ6nSV6Ah89+ MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr4960159qge.91.1395085548856; Mon, 17 Mar 2014 12:45:48 -0700 (PDT) Received: by 10.140.36.163 with HTTP; Mon, 17 Mar 2014 12:45:48 -0700 (PDT) X-Originating-IP: [84.109.83.45] In-Reply-To: References: <20140314161047.GD1390@x220.localdomain> Date: Mon, 17 Mar 2014 21:45:48 +0200 Message-ID: From: Daniel Kaminsky To: sabu kurian Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Segmentation Fault on printf() X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 19:44:18 -0000 Sabu, I think that in this case the packet length is zero which will result in nothing from mtod. Daniel On Sun, Mar 16, 2014 at 3:03 PM, sabu kurian wrote: > Hello chris, > > Thanks for your reply. I tried dumping the contents of mbuf as you have > suggested. > This is what I get: > > dump mbuf at 0x0x6c7620, phys=7f34d91eba28, buf_len=59488 > pkt_len=0, ol_flags=0, nb_segs=0, in_port=0 > > and soon after that I get a segmentation fault. Do you have any idea on > what could be causing it ? > > Regards > > > > On Fri, Mar 14, 2014 at 9:40 PM, Chris Wright wrote: > > > * sabu kurian (sabu2kurian@gmail.com) wrote: > > > Hello friends, > > > > > > I'm trying to print the ether_type for a packet that I captured from a > > port > > > on my machine. Suppose 'm' holds the packet. 'm' is of type 'struct > > > rte_mbuf'. Intels API reference for DPDK says 'ether_type' is of > > uint16_t. > > > I used the following code to retrieve ether_type. > > > > > > void * eth_type; > > > struct ether_hdr *eth; > > > > > > eth = rte_pktmbuf_mtod(m, struct ether_hdr *); > > > eth_type = ð->ether_type; > > > > > > printf("\n Type is %" PRIu16 , *((uint16_t *)eth_type)); > > > > Looks ok, albeit slightly overly complicated. > > > > struct ether_hdr *eth; > > uint16_t eth_type; > > > > eth = rte_pktmbuf_mtod(m, struct ether_hdr *); > > eth_type = eth->ether_type; > > printf("\n Type is %" PRIu16 , eth_type)); > > > > This would remove all the extra casting. Perhaps the mbuf is the problem > > here. And if so, the above snippet would segfault on eth->ether_type > > showing you that mbuf is invalid. > > > > You could try to (above mtod): > > > > rte_pktmbuf_dump(m, sizeof(struct ether_hdr)); > > > > as that will show key contents of mbuf and packet data (and do some > > basic validation along the way). > > > > thanks, > > -chris > > >