From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D3606A00C5; Wed, 29 Apr 2020 22:25:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7F41B1D984; Wed, 29 Apr 2020 22:25:33 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id BC0DE1D97E for ; Wed, 29 Apr 2020 22:25:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588191931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rINLZdwkqqja9A6zLw9D8pUPSslOnNlMcd2gtgCCYHg=; b=ZrBrMFJclc1GA/Qo1Td8o0EYu0HTQ76atwTLUNnd1JH6HUicUfIJjZOiO1CyUALeibXfE8 P/x0R822hhnEv+a7lxUS3FxSkRxrcv30640s12VO9F2PPwR5MTGREp8Zq6qR9pgDuA/Wn0 TvRrE9BbmyYqrlHL3hOfQXThXhZ5AL4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-371-b3P4GMcXOQ-ZmEOehy12yw-1; Wed, 29 Apr 2020 16:25:27 -0400 X-MC-Unique: b3P4GMcXOQ-ZmEOehy12yw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BD8FF107B275; Wed, 29 Apr 2020 20:25:25 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (ovpn-114-167.rdu2.redhat.com [10.10.114.167]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 632435C1BE; Wed, 29 Apr 2020 20:25:24 +0000 (UTC) From: Aaron Conole To: "Ananyev\, Konstantin" Cc: Honnappa Nagarahalli , "dev\@dpdk.org" , Gavin Hu , Olivier Matz , nd References: Date: Wed, 29 Apr 2020 16:25:23 -0400 In-Reply-To: (Konstantin Ananyev's message of "Wed, 29 Apr 2020 18:02:22 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] ISSUE: compiling with asan+ubsan X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" "Ananyev, Konstantin" writes: >> >> >> 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../confi= g >> >> >> - >> >> >> 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_ta= ble >> >> >> -Ilib/librte_port -I../lib/librte_port -Ilib/librte_sched >> >> >> -I../lib/librte_sched - Ilib/librte_ip_frag -I../lib/librte_ip_fra= g >> >> >> -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_pipel= ine >> >> >> -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/pc= i >> >> >> -I../drivers/bus/pci/linux -Idrivers/bus/vdev -I../drivers/bus/vde= v >> >> >> -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=3Dalways >> >> >> -fsanitize=3Daddress,undefined -fno-omit-frame-pointer -pipe >> >> >> -D_FILE_OFFSET_BITS=3D64 -Wall -Winvalid-pch -Werror -O2 -g -inclu= de >> >> >> 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=3Dnative -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 4609626= 112 >> >> >> bytes >> > I have a machine where I hit this error for a lot of other files every >> > time I do a fresh compile. I attribute that to low swap space. >>=20 >> I am shocked that a translation unit should be 4.6G? That's >> unbelievably HUGE - there's no way that's correct. There must be >> something going on with your machine - I've only ever seen it with >> test_ring.c and it's very consistent. >>=20 >> >> > >> >> > 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 >> > The compilation time issue was attributed to compiler version. We saw >> > the issues only on clang. GCC did not show any problems. >> > Is this problem something new? >>=20 >> This is happening on GCC. Actually, the meson build with clang + >> asan&ubsan doesn't even work right. >>=20 >> >> seems too much. >> >> > Will try to have a look later this week. >> >> >> >> Okay - glad I'm not the only one. My only theory is that all the inl= ining is >> >> exploding the size of the file during the translation unit processing= . >> >> >> >> I ran it through the preprocessor and didn't see any large arrays cre= ated >> >> anywhere. But there are loads of calls to the rte_ring that are tagg= ed as >> >> "always inline" - even the test_enqueue and test_dequeue functions ar= e >> >> "always inline" and they are quite large. Just a completely unfounde= d guess. >>=20 >> As a test, I changed the attributes in test_ring.h to remove the >> always_inline - and I was finally able to complete a build with >> asan&ubsan using GCC. This is on x86_64 platform. Just running the >> fast tests. >>=20 >> Look at test_ring_enqueue/test_ring_dequeue - those functions are large >> and branchy. The compiler is being forced to inline them. I'm not sure >> how many other places that's happening, but it simply cannot be >> correct. They're used all over that test_ring.c translation unit. >> That's a huge amount of expansion required by the compiler and a bunch >> of flow analysis being thrown away. You've pessimized for compilation >> memory. >>=20 >> Can you please take a closer look? > > Can you try: > http://patches.dpdk.org/patch/69559/ > On my machine it takes less then 10s and 300MB after the patch. Sure! Thanks! >>=20 >> >> CC'd Honnappa (and others) to take a look. >> >> >> >> >> >> >> >> This is in a constrained (read: container) environment. I guess o= ne >> >> >> 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 als= o. >> >> >> >> >> >> -Aaron