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 29A9BA0093 for ; Fri, 17 Jun 2022 07:45:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E692440698; Fri, 17 Jun 2022 07:45:48 +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 4E5BF40689 for ; Fri, 17 Jun 2022 07:45:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655444747; 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=Z/hkGuKxZTFwjx98UwnLunwp5r/g3inoJ5bwFRLxMD0mqDWOWcZ+9ePMc+ABRxDrI+oXLx HrIo4+zDBm3Y+k//w5eISMnaX8Ppzu6GJ4wzaZEhEY0hhjbqaPbrb/6ZC4glsKFMP9qnnQ mGlLEujOFtE08hnZXvfOmOz+HSltvE8= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-622-svJK_BE5NW6nhkVEqooQow-1; Fri, 17 Jun 2022 01:45:46 -0400 X-MC-Unique: svJK_BE5NW6nhkVEqooQow-1 Received: by mail-lf1-f69.google.com with SMTP id j3-20020a05651231c300b0047dbea7b031so1822873lfe.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=jvsjlSN/g5mGcbnm5XRyF64RhjMWzxo6etapYFeXwDGKfsyE0GgBYFS5EIkdreRASk 6jQW3y41y+9S/AmVoelx/PCWCabV6Sno2g7yN5bt7njHwlZ3yM1tNn96CDipMhydvsge Kf6MBorNvas0BddTJwYZO4Hm/7R/76O2/LWWEx22gF/AscRU9NlKX1mYL6Mo/w/r1aQj 2yjpp2E2JYN+jiNT6Cr1cC2x9Xriu6BLwzLIhpMl6fW+wVCOvIvgljwMojkfJNJQXhhV ahQiuqS7Rojuyw3f7aIc8z2vKuDoiaZA4/U5gvBIGk0jLjrAdLyPgJrQ6E2paieuLz1V tMCQ== X-Gm-Message-State: AJIora9+uCWwCSvfJX6fUuX+z3yVMmh3+XgYm3gEzFgvMD+ehHqfr89V 93VGFlXLBm0chZJWiBfZTzNkKx5qytGKqnj0sjprLfRvntBB9Mf+DHlTGDESdC3eCGcTfWh5wzt ppN3FZR7bkubMG1kAv1lwzQ== X-Received: by 2002:ac2:5201:0:b0:479:3923:9559 with SMTP id a1-20020ac25201000000b0047939239559mr4623855lfl.553.1655444744809; 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: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-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