From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B6C5EA0093; Fri, 17 Jun 2022 07:45:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 94D0D427F3; Fri, 17 Jun 2022 07:45:51 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 608A941148 for ; Fri, 17 Jun 2022 07:45:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655444749; 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=7fxFaU7penZM6SffJj3/cehgj608Ly3pceaXjPygRBE=; b=Mqvd9SwwFedWwio8n3OB2KmyQxzKQ2vn7hs9hXKLhB1aMXy96d8RvDunnnbF7gZUgWwe2e Sf+GG0hSJIe0DcQEkZs/O30n1Vjgl07cyH1Ujga1SQtYs3NkHV7J1AEa8NbdSq7kNK1lqI 7a+VCqy66GAIZSm0kJaIObGCaIZenwQ= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-198-nS6G77v4PT-Zko6_Kmz5nA-1; Fri, 17 Jun 2022 01:45:46 -0400 X-MC-Unique: nS6G77v4PT-Zko6_Kmz5nA-1 Received: by mail-lj1-f197.google.com with SMTP id g3-20020a2e9cc3000000b00253cc2b5ab5so422279ljj.19 for ; Thu, 16 Jun 2022 22:45:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7fxFaU7penZM6SffJj3/cehgj608Ly3pceaXjPygRBE=; b=AilMvJJoehIMJy6lPM1Bf71mW04LF4FuZbhSZ/g0kcccHH3IUUy1kUyb4eZLYpKfEc d+p4bFnppYIEW3en+rBGEdtIn+7ia7VDqddo8KW9boosHxpfkf9ucJmV+e90XKEG6ZXp WINQdSMiopinrX9X9CcZ/3U4tssuuCnL8lxeeSvZj9EawqC7iaQl2At0CafTd3iR5KB+ W8B4I6M1epx6gCco2t1VX0aWO+s5hjsttGor6HvtE2J8BTD6A6Uelv1IYxcFc7q6YPrv U7zVTGTjijCy88U6EGfDnZoApy4s/rSh+rbT5jllEwmEXkNvi6ROPMJpnfL3U0UDtohW nyhA== X-Gm-Message-State: AJIora9pfU08OmLV3i5Pu1X+queEgkMynY/h1oyrnRz8G+h7IZ0QrCVe Uy0QQB9wtji0pQl082d4z+KHTbHiMJ9gAjCibmEl6BbLosdduDxsWR4vJFntfTsxvoXoRcdylv3 HxFMXlAlkw3NDWwz4/jY= X-Received: by 2002:ac2:5201:0:b0:479:3923:9559 with SMTP id a1-20020ac25201000000b0047939239559mr4623858lfl.553.1655444744810; Thu, 16 Jun 2022 22:45:44 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t4MMsyzPpwQljNaaN7XOi7IPTv9/g33BCHpX1OPkuAMLs6v0sksM1MTXJzrh8saUExGEDFJJSjfyDkimSAQIw= X-Received: by 2002:ac2:5201:0:b0:479:3923:9559 with SMTP id a1-20020ac25201000000b0047939239559mr4623845lfl.553.1655444744525; Thu, 16 Jun 2022 22:45:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Marchand Date: Fri, 17 Jun 2022 07:45:33 +0200 Message-ID: Subject: Re: dpdk address sanitizer To: "Juan Pablo L." Cc: "users@dpdk.org" , "Burakov, Anatoly" , Dmitry Kozlyuk , dev , ci@dpdk.org Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hello, On Fri, Jun 17, 2022 at 6:08 AM Juan Pablo L. wrote: > > Hello, I am new to dpdk ... i would like to trace memory usage and detect= memory leaks, valgrind as well as address sanitizer (gcc) report some memo= ry loss at application end. For the life of me, i cannot figure it out ... = i just write a simple program that has the rte_eal_init + rte_eal_cleanup a= nd i get the following error (also tried helloworld from examples, with sam= e results): > > =3D=3D3399=3D=3DERROR: AddressSanitizer: stack-buffer-overflow on address= 0x7f6ca3efb480 at pc 0x7f6ca7162b61 bp 0x7f6ca3efb450 sp 0x7f6ca3efac00 > WRITE of size 24 at 0x7f6ca3efb480 thread T-1 > #0 0x7f6ca7162b60 in __interceptor_sigaltstack.part.0 (/lib64/libasan.so.= 8+0x61b60) > #1 0x7f6ca71d9337 in __sanitizer::UnsetAlternateSignalStack() (/lib64/lib= asan.so.8+0xd8337) > #2 0x7f6ca71c90f4 in __asan::AsanThread::Destroy() (/lib64/libasan.so.8+0= xc80f4) > #3 0x7f6ca679b000 in __GI___nptl_deallocate_tsd (/lib64/libc.so.6+0x8a000= ) > #4 0x7f6ca679dc9d in start_thread (/lib64/libc.so.6+0x8cc9d) > #5 0x7f6ca68235df in __GI___clone3 (/lib64/libc.so.6+0x1125df) > > Address 0x7f6ca3efb480 is a wild pointer inside of access range of size 0= x000000000018. > SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/libasan.so.8+0x6= 1b60) in __interceptor_sigaltstack.part.0 > Shadow bytes around the buggy address: > 0x0fee147d7640: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 > 0x0fee147d7650: 00 00 00 00 00 00 00 00 00 06 f2 f2 f2 f2 00 00 > 0x0fee147d7660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d7670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d7680: 00 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 > =3D>0x0fee147d7690:[f3]f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d76a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d76b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d76c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d76d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d76e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > =3D=3D3399=3D=3DABORTING > > I am not sure what I m doing wrong but it is very frustrating. On top of = that, I try other scenarios and see if I can just "ignore" that and still d= etect other memory leaks but it does not work. I get memory from rte_malloc= and don't free it and I still get the above report only, I do not get any = report from the memory I leaked intentionally ... no difference what so eve= r .... I tried the same with the helloworld example and I get the same resu= lts .... I experienced the same issue recently on Fedora 36. I did not investigate. I think I waived this warning, by setting ASAN_OPTIONS=3D"use_sigaltstack=3D0" in the environment. HTH. --=20 David Marchand