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 8E334A00C2; Wed, 22 Apr 2020 14:55:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 802321D61F; Wed, 22 Apr 2020 14:55:06 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id 7C7CD1D61E for ; Wed, 22 Apr 2020 14:55:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587560103; 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=a2F5C+0LYRTgeA2+KAzuMY8dbqTTFRW/2+S1cbwrEFM=; b=TgZdvreSrJhMiqRHpQP2uukt8Tuwt29sQyN9RhX8ZH6OvkQ2TG81Jxf4YQw+8AI8wipPku 8PRagcBMNjb4vLZl2Uge6KIbfdJhdcZtXVRZMcRvgKbqaVa3L8fM722Z/XhE9Vod96Mhjf GU+xrnbVzQLE8gmGtcxcsMKV/ILlb98= 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-402-MXS6tnxqOx6zNJxkYvl38Q-1; Wed, 22 Apr 2020 08:55:01 -0400 X-MC-Unique: MXS6tnxqOx6zNJxkYvl38Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8178A13FA; Wed, 22 Apr 2020 12:55:00 +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 EDA416084B; Wed, 22 Apr 2020 12:54:58 +0000 (UTC) From: Aaron Conole To: Honnappa Nagarahalli Cc: "Ananyev\, Konstantin" , "dev\@dpdk.org" , Gavin Hu , Olivier Matz , nd References: Date: Wed, 22 Apr 2020 08:54:57 -0400 In-Reply-To: (Honnappa Nagarahalli's message of "Tue, 21 Apr 2020 20:29:53 +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.13 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" Honnappa Nagarahalli writes: > > >>=20 >> "Ananyev, Konstantin" writes: >>=20 >> > 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=3Dalways >> >> -fsanitize=3Daddress,undefined -fno-omit-frame-pointer -pipe >> >> -D_FILE_OFFSET_BITS=3D64 -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=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 4609626112 >> >> 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. 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. >> > >> > I also noticed that test_ring.c compilation takes a huge amount of tim= e and >> memory. >> > On my box it not as bad as yours (up to ~100 sec and ~1 GB) , but sti= ll > 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? This is happening on GCC. Actually, the meson build with clang + asan&ubsan doesn't even work right. >> seems too much. >> > Will try to have a look later this week. >>=20 >> Okay - glad I'm not the only one. My only theory is that all the inlini= ng is >> exploding the size of the file during the translation unit processing. >>=20 >> I ran it through the preprocessor and didn't see any large arrays create= d >> anywhere. But there are loads of calls to the rte_ring that are tagged = as >> "always inline" - even the test_enqueue and test_dequeue functions are >> "always inline" and they are quite large. Just a completely unfounded g= uess. 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. 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. Can you please take a closer look? >> CC'd Honnappa (and others) to take a look. >>=20 >> >> >> >> 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