[dpdk-users] DPDK-16.07: segfault when calling rte_eth_stats_get() from secondary process

[Sruthi Yellamraju]

I tested with the same binaries for vmxnet3 and that works fine. Could
there be an issue in fm10k stats APIs?

On Thu, Nov 3, 2016 at 9:45 PM, Sruthi Yellamraju <ysruthi at gmail.com> wrote:

> Both primary and secondary processes are built and running off 16.07
>
>
> On Thursday, November 3, 2016, XIAO Xiaohong <Xiaohong.Xiao at alcatel-sbell.
> com.cn> wrote:
>
>> Hello
>> You said your primary process calls a shared library, then what's the
>> DPDK version this shared library is built on?
>> Can you make sure the primary and secondary process both are using same
>> DPDK version?
>>
>> -----Original Message-----
>> From: users [mailto:users-bounces at dpdk.org] On Behalf Of Sruthi
>> Yellamraju
>> Sent: 2016年11月4日 6:49
>> To: users at dpdk.org
>> Subject: [dpdk-users] DPDK-16.07: segfault when calling
>> rte_eth_stats_get() from secondary process
>>
>> Hi,
>>
>> I am using DPDK 16.07 with fm10k. I am seeing segfaults when calling
>> rte_eth_stats_get() API from a secondary process.
>>
>> The primary process doesnt call DPDK APIs directly and hence doesnt link
>> against DPDK Libraries. The primary process uses a shared library that in
>> turn is using DPDK APIs and links with DPDK libraries. All DPDK libraries
>> are built as static libraries.
>>
>> The secondary process uses DPDK APIs directly and hence links against the
>> DPDK static libraries directly.
>>
>> When i run the secondary process to get stats (something like
>> dpdk-procinfo) application, it segfaults (Error 14). gdb shows:
>> (gdb) bt
>> #0  0x00007fffeacd72bc in ?? ()  --> points to stats API offset in the
>> primary processes'  shared library
>> #1  0x00000000006761d7 in fm10k_update_hw_stats ()
>> #2  0x0000000000650dee in fm10k_stats_get ()
>> #3  0x000000000043803d in rte_eth_stats_get ()
>> #4  0x0000000000a68663 in do_get_stats (argc=<value optimized out>,
>> argv=0x7fffffffe478) at dpdk_status.c:225
>> #5  main (argc=<value optimized out>, argv=0x7fffffffe478) at
>> dpdk_status.c:501
>>
>> Any clues on why this could be happening? I am guessing this  needs some
>> linker magic to get it to work. Not sure what exactly. I played with a
>> couple of options , but in vain.
>>
>> Any pointers will be greatly appreciated.
>>
>> Thanks!
>>
>