DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Aaron Conole <aconole@redhat.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] ISSUE: compiling with asan+ubsan
Date: Tue, 21 Apr 2020 16:20:10 +0000	[thread overview]
Message-ID: <BYAPR11MB330181BD6EC3AD86D9854D839AD50@BYAPR11MB3301.namprd11.prod.outlook.com> (raw)
In-Reply-To: <f7tmu74rhmb.fsf@dhcp-25.97.bos.redhat.com>


Hi Aaron,
 
> While compiling with asan and ubsan I run into the following error:
> 
> FAILED: app/test/app@test@@dpdk-test@exe/test_ring.c.o
> 
> gcc -Iapp/test/app@test@@dpdk-test@exe -Iapp/test -I../app/test -Ilib/librte_acl -I../lib/librte_acl -I. -I../ -Iconfig -I../config -
> Ilib/librte_eal/include -I../lib/librte_eal/include -Ilib/librte_eal/linux/include -I../lib/librte_eal/linux/include -Ilib/librte_eal/common -
> I../lib/librte_eal/common -Ilib/librte_eal/x86/include -I../lib/librte_eal/x86/include -Ilib/librte_eal -I../lib/librte_eal -Ilib/librte_kvargs -
> I../lib/librte_kvargs -Ilib/librte_bitratestats -I../lib/librte_bitratestats -Ilib/librte_ethdev -I../lib/librte_ethdev -Ilib/librte_net -
> I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring -I../lib/librte_ring -
> Ilib/librte_meter -I../lib/librte_meter -Ilib/librte_metrics -I../lib/librte_metrics -Ilib/librte_bpf -I../lib/librte_bpf -Ilib/librte_cfgfile -
> I../lib/librte_cfgfile -Ilib/librte_cmdline -I../lib/librte_cmdline -Ilib/librte_cryptodev -I../lib/librte_cryptodev -Ilib/librte_distributor -
> I../lib/librte_distributor -Ilib/librte_efd -I../lib/librte_efd -Ilib/librte_hash -I../lib/librte_hash -Ilib/librte_eventdev -I../lib/librte_eventdev -
> Ilib/librte_timer -I../lib/librte_timer -Ilib/librte_fib -I../lib/librte_fib -Ilib/librte_rib -I../lib/librte_rib -Ilib/librte_flow_classify -
> I../lib/librte_flow_classify -Ilib/librte_table -I../lib/librte_table -Ilib/librte_port -I../lib/librte_port -Ilib/librte_sched -I../lib/librte_sched -
> Ilib/librte_ip_frag -I../lib/librte_ip_frag -Ilib/librte_kni -I../lib/librte_kni -Ilib/librte_pci -I../lib/librte_pci -Ilib/librte_lpm -I../lib/librte_lpm -
> Ilib/librte_ipsec -I../lib/librte_ipsec -Ilib/librte_security -I../lib/librte_security -Ilib/librte_latencystats -I../lib/librte_latencystats -
> Ilib/librte_member -I../lib/librte_member -Ilib/librte_pipeline -I../lib/librte_pipeline -Ilib/librte_rawdev -I../lib/librte_rawdev -Ilib/librte_rcu -
> I../lib/librte_rcu -Ilib/librte_reorder -I../lib/librte_reorder -Ilib/librte_stack -I../lib/librte_stack -Idrivers/mempool/ring -
> I../drivers/mempool/ring -Idrivers/mempool/stack -I../drivers/mempool/stack -Idrivers/event/skeleton -I../drivers/event/skeleton -
> Idrivers/bus/pci -I../drivers/bus/pci -I../drivers/bus/pci/linux -Idrivers/bus/vdev -I../drivers/bus/vdev -Idrivers/net/bonding -
> I../drivers/net/bonding -Idrivers/net/ring -I../drivers/net/ring -Ilib/librte_power -I../lib/librte_power -Ilib/librte_pdump -I../lib/librte_pdump
> -Ilib/librte_compressdev -I../lib/librte_compressdev -fdiagnostics-color=always -fsanitize=address,undefined -fno-omit-frame-pointer -pipe
> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat-
> nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -
> Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-missing-field-initializers -march=native -mno-avx512f -
> DALLOW_EXPERIMENTAL_API -Wno-format-truncation -D_GNU_SOURCE  -MD -MQ 'app/test/app@test@@dpdk-test@exe/test_ring.c.o'
> -MF 'app/test/app@test@@dpdk-test@exe/test_ring.c.o.d' -o 'app/test/app@test@@dpdk-test@exe/test_ring.c.o' -c
> ../app/test/test_ring.c
> 
> cc1: out of memory allocating 65536 bytes after a total of 4609626112
> bytes

I also noticed that test_ring.c compilation takes a huge amount of time and memory.
On my box it not as bad as yours (up to ~100 sec and  ~1 GB) , but still seems too much.
Will try to have a look later this week.

> 
> This is in a constrained (read: container) environment.  I guess one way
> of resolving would be to allocate more memory to the container, but I'm
> also curious why the object files are getting so large?  Should I
> consider this a bug or "working as intended"?  This will have
> implications if we want asan/ubsan under the travis build also.
> 
> -Aaron


  reply	other threads:[~2020-04-21 16:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21 15:19 Aaron Conole
2020-04-21 16:20 ` Ananyev, Konstantin [this message]
2020-04-21 16:49   ` Aaron Conole
2020-04-21 20:29     ` Honnappa Nagarahalli
2020-04-22 12:54       ` Aaron Conole
2020-04-29 18:02         ` Ananyev, Konstantin
2020-04-29 20:25           ` Aaron Conole
2020-04-29 22:09           ` Aaron Conole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BYAPR11MB330181BD6EC3AD86D9854D839AD50@BYAPR11MB3301.namprd11.prod.outlook.com \
    --to=konstantin.ananyev@intel.com \
    --cc=aconole@redhat.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).