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 676B6A0540 for ; Sun, 19 Jun 2022 04:39:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3ABD7400EF; Sun, 19 Jun 2022 04:39:58 +0200 (CEST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-oln040092074097.outbound.protection.outlook.com [40.92.74.97]) by mails.dpdk.org (Postfix) with ESMTP id D729340042; Sun, 19 Jun 2022 04:39:56 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I3JADduo5424Xg8OZmZjCpxpb7FL9txYdFnbMCjTvkw+6DrepuEVCtF7rqMoI2YZTx0uorgWrSUNJ2Dt8R07WiQyRX9OKKHnZIEdEr5HtF5uw/axAxvWAz6K+a9zKb7QrFyqFCXplSI0yCC/UN/To4CqQHpl3ot2E5abCGhSWVyDcqRSWq/rg363Lan/MTpgh89wdC/ofu7KKj5hJMZ6FsZMFm2Usyojn3MZ3/cMn0t0Le9VCs0X7603yQgFnEGQdPi5nzX3aPBgxkHlHWwhRpWL1veJbIW+fKjC+tbZyeW+7lC0YVsGOKvXdSVyZK9wAU/LKRdWyZXQ4cmhHFCrkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S97D2Lbi1L64MR2bGJ4MIYW7WvpF8ytYfOdh8wBq/C8=; b=Gt6GT8Mt48bm8Fg0/Yniq4WrPQwxm0D+p4H9TRoG+wDI4p96zy4xOYsQTdeOKngy3rNN0dQ6TJ2MDA52hMW7bxia4kc9Ufy5aU9TnMwJs8kRI98xPHOBpXYCZ1ghcqrcutgjeQtJvlC2fKvohK3CAgejWwkFIoU2V60HnL49xmsrvvA2jy+SEF5dBqWCAiG2sMVgJNql0e4bxiV1Yc6Oswj8iwhLHi0IQ48VO5a9fWGU3vniQFERU+k1lDSGJ/ysYMD9lmjQYiI37UIkgAFHNiXT3XKkR8hXJK7VEyhKjwwM8St+J4rAOpt0Uiokqe2WVYtpDfHfcYR0t8DVsHVrWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S97D2Lbi1L64MR2bGJ4MIYW7WvpF8ytYfOdh8wBq/C8=; b=BZTABvQK70ZnhXl8xqSEdLf0luJ1SVBjzl1OIFUSJvcNW3ZZZCb/GeG4mWnxjKsLsJ7FgB4X3rQj2hf/79xYmzbmuxrWDetBNrgInOaSvoMiNxGn94ubNs/+G2XRsN3oQcKpSZ/N4il8FDXZwK7UdH5pIdRz7BBrSE7BYxLrl+uuUDuYQ2WcK4MZS1ZvfjF7r7PSawfcXFlMEvaygOOrdeW9pbgAuX0Mj/UgAkr1iV17UHIl+o11/2DkLcrjqww3E+AX0/El0U+/cSmYpoQnQG90KEtEE/qAIwHD76tl1B68m7W/m0Ydxeq7RU9A7Dmd006a8DochCuMz+b1vZwF4w== Received: from AM0PR04MB6692.eurprd04.prod.outlook.com (2603:10a6:208:178::25) by DB9PR04MB8188.eurprd04.prod.outlook.com (2603:10a6:10:25e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.20; Sun, 19 Jun 2022 02:39:55 +0000 Received: from AM0PR04MB6692.eurprd04.prod.outlook.com ([fe80::71ee:cdb:5413:1200]) by AM0PR04MB6692.eurprd04.prod.outlook.com ([fe80::71ee:cdb:5413:1200%4]) with mapi id 15.20.5353.019; Sun, 19 Jun 2022 02:39:55 +0000 From: Juan Pablo L. To: Stephen Hemminger , David Marchand CC: "users@dpdk.org" , "Burakov, Anatoly" , Dmitry Kozlyuk , dev , "ci@dpdk.org" Subject: Re: dpdk address sanitizer Thread-Topic: dpdk address sanitizer Thread-Index: AQHYgf7T2wIwZUgikkik372p4IwcSa1TFu2AgACwqoCAAj/iag== Date: Sun, 19 Jun 2022 02:39:55 +0000 Message-ID: References: <20220617091751.05b64e64@hermes.local> In-Reply-To: <20220617091751.05b64e64@hermes.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: abf6af25-db8d-da82-5e6b-d301584ef44c x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [5BfixFhAOcppRLLgLz0XQlLoVdYNFVRB] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 011770b2-9271-4c7e-ee18-08da519cfecd x-ms-traffictypediagnostic: DB9PR04MB8188:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QbpADn4+77NZbZiVpvewfqpm36JWVk2PoXJKJKsQ6z4D+PdwucBsmWhrq0B1OCcqt99BIX64QKW5NBzzWMabtm6NFzT1+RrxbkNA+C0nQ1+rITaihUQXR56BJF5rzq+FH80m5agso6yEcHcDxo84k5Lw/MQiKM0eyL2BSqxE2qh5gsV0sarEOln0uccGlJ5/2D7EX/rfGEA1LYxCJx9+elw2RusfCoozeR0yS6DCEdCO3gffye8yCs+NtV9Npmt/Sa9mCkJ+MYELZgCU2z49d2vNWpbnhKmDb7Axe2KSooplIP7AcCcyMtxDDzbKB73/gHKcGLQt0r4xTsWfK3j570AZx458uhgK24Yg6Tt5iTBazMuq7ldZN8UgzqfS53TUmXbP1Xj3jkXaZ/BLoLfxYrUaJstCCrFbLOGA446xMvb2AeJYOsYvVLFX6vWiquuh/+9rczw1Dn71f8vLAqsnU0NFqLcqPvQ8ZCQ42xgCSguZCz/6zRaGVsnVBQx0vHTS2TRWx1SpBlwzMT7Jpin/sdOxq9KvkCciize9UwW0gHiK2wC+QFMBF+Zsd4YgJABqgkN4QHOPpxNAwCtqZneldw== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?F5VPHxGb8qsu7OCk9SMO0I907qCBvk97s/779FgDYRohHuXGVc7Tmh9YFbwp?= =?us-ascii?Q?JCD/FWDuBCrX270m51m4CyRfNiw/7+7xjzDvqMtXyqfVujQAJsr/CDfwYJhh?= =?us-ascii?Q?LKB0gsISg8b2sk/Wbk4mh5hHMhUniP1dLCbT5Urvd9eQPuVWvKTEOU1t/x7q?= =?us-ascii?Q?XZBOvhH8+ijJBLAsoqaBXT259c3Vttw4CCODy5f3sPII+3G8rMwAAY7lwbDr?= =?us-ascii?Q?dedMonRyZu8g8ERik3rqt9om1s0zS2xquf3n+MFOOjc54rqTeox2ERTsb6d0?= =?us-ascii?Q?btBIA3XYAr2QmgVim0KVCZXz2hNBsRIzvRbHSFKj3sQDGSiCywq43+CgQgBv?= =?us-ascii?Q?0Lea6Vawk/fTw+D2VXd6Gr0bGwJeQgMokESZ9VPWeIG4l5gf3M+pcxi57DcP?= =?us-ascii?Q?dd5bKGIX+/elCbguYBDt1xiPCG+aX3wuvFK5eKs2I8tav/Va6MlUvMmuNtN3?= =?us-ascii?Q?aKkMMI91rQcDyJanmUmHXLd4mgweGapL70VKMlz3FwqKJ3IIKDJND+eepibj?= =?us-ascii?Q?JmByu2ugjz2O3okHWgmo4at6/qC0FNOlmjGn5w99P/a+rL1zQS0GEnsB9kmZ?= =?us-ascii?Q?12c6lHiNLClBO2OSzjfaj/T8PqGvj+5Z81cKVqRJCKwc71mbtwbIYiuGQ4ux?= =?us-ascii?Q?jnAIly1RkuY/Ev5pcBmFP8HlBLUNG1BwnUhA77DEf5p6zoeEQhohPV+WktpV?= =?us-ascii?Q?4IcnX0bu1mYDgvK1Qaei+iSEFAC0pyLg5kyiLU2JbFzkLdl+f/8g/CGkPRs0?= =?us-ascii?Q?H3dfNuH5zWcNHA3kC3Q061D08yiEIGFvQdb5G4a6gcNxsgmeUSyQTeMuT62y?= =?us-ascii?Q?GRbTagfpZNxZo6esIhgxUzvYwnCbFuwzMOobihHfsn+INfWfgusHQZx7CM3b?= =?us-ascii?Q?cjtOpLL0Lo/HI+7xRUKlx8qaPvByJ6kzMPBxic9wfAokJUiG7ue3hUKFAC2c?= =?us-ascii?Q?ie4zsaZK3STAraVmj0R7oPNbu+mZ7wQO+xW8oMVgFCh68X0tL3VTBE7YGh+2?= =?us-ascii?Q?D8+zoTV1l1yBF4wIVhAsDbxigPZvRqEuGND1HCqS2HHCd2DD1XH2llXOvS2+?= =?us-ascii?Q?pAR6/xFPc8snCOo8IERkD20aHhiq2wfdMhmfH3SREFke9e7/56s2w3c4sy4i?= =?us-ascii?Q?aBWEpW9ytQRIPAtLsm+16+kJb5SWny8iwV23G87ucQuFO7QIvvJBnpmPHu9r?= =?us-ascii?Q?t9Er4m1tHlmfCpK/haqbDL/xX23MtWJVJsmDWczGcivmpxYdxPpLhkaYK5a9?= =?us-ascii?Q?g7yzNH39AVuVVxtvc2hNbbTMbwAJI25ttmJyrdxIousdXSxfCk3wH86XmeXy?= =?us-ascii?Q?AmLYcC5Qt+bPzEKnTVbr+uSCnrL3/IExPp0/wh6NNWeRr+dG0Fqbs8LALFBG?= =?us-ascii?Q?YtToxQAMU/QTdz8ayjg/SRzAAbv8/RDjAblKy3/WHdH4rrfkIkPOVvX0k/zZ?= =?us-ascii?Q?x56DF9x6QKo=3D?= Content-Type: multipart/alternative; boundary="_000_AM0PR04MB66927D96934577B30C800F12D9B19AM0PR04MB6692eurp_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-03a34.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR04MB6692.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 011770b2-9271-4c7e-ee18-08da519cfecd X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2022 02:39:55.7690 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR04MB8188 X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org --_000_AM0PR04MB66927D96934577B30C800F12D9B19AM0PR04MB6692eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for your feedback, i will look into that .. any suggestions on wh= at technique I can use to find memory leaks, invalid accesses, etc etc ....= ? thanks!!! ________________________________ From: Stephen Hemminger Sent: Friday, June 17, 2022 4:17 PM To: David Marchand Cc: Juan Pablo L. ; users@dpdk.org ; Burakov, Anatoly ; Dmitry Kozlyuk ; dev ; ci@dpdk.org Subject: Re: dpdk address sanitizer On Fri, 17 Jun 2022 07:45:33 +0200 David Marchand wrote: > 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 dete= ct memory leaks, valgrind as well as address sanitizer (gcc) report some me= mory 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= and i get the following error (also tried helloworld from examples, with s= ame results): > > > > =3D=3D3399=3D=3DERROR: AddressSanitizer: stack-buffer-overflow on addre= ss 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.s= o.8+0x61b60) > > #1 0x7f6ca71d9337 in __sanitizer::UnsetAlternateSignalStack() (/lib64/l= ibasan.so.8+0xd8337) > > #2 0x7f6ca71c90f4 in __asan::AsanThread::Destroy() (/lib64/libasan.so.8= +0xc80f4) > > #3 0x7f6ca679b000 in __GI___nptl_deallocate_tsd (/lib64/libc.so.6+0x8a0= 00) > > #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= 0x000000000018. > > SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/libasan.so.8+0= x61b60) 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 o= f that, I try other scenarios and see if I can just "ignore" that and still= detect other memory leaks but it does not work. I get memory from rte_mall= oc and don't free it and I still get the above report only, I do not get an= y report from the memory I leaked intentionally ... no difference what so e= ver .... I tried the same with the helloworld example and I get the same re= sults .... > > 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. > Looks like the alternate signal stack allocated inside address sanitizer is= not big enough. --_000_AM0PR04MB66927D96934577B30C800F12D9B19AM0PR04MB6692eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you for your feedback, i will look into that .. any suggestions on wh= at technique I can use to find memory leaks, invalid accesses, etc etc ....= ?

thanks!!!
From: Stephen Hemminger <= ;stephen@networkplumber.org>
Sent: Friday, June 17, 2022 4:17 PM
To: David Marchand <david.marchand@redhat.com>
Cc: Juan Pablo L. <jpablolorenzetti@hotmail.com>; users@dpdk.o= rg <users@dpdk.org>; Burakov, Anatoly <anatoly.burakov@intel.com&g= t;; Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>; dev <dev@dpdk.org&g= t;; ci@dpdk.org <ci@dpdk.org>
Subject: Re: dpdk address sanitizer
 
On Fri, 17 Jun 2022 07:45:33 +0200
David Marchand <david.marchand@redhat.com> wrote:

> Hello,
>
> On Fri, Jun 17, 2022 at 6:08 AM Juan Pablo L.
> <jpablolorenzetti@hotmail.com> wrote:
> >
> > Hello, I am new to dpdk ... i would like to trace memory usage an= d detect memory leaks, valgrind as well as address sanitizer (gcc) report s= ome memory 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 and i get the following error = (also tried helloworld from examples, with same results):
> >
> > =3D=3D3399=3D=3DERROR: AddressSanitizer: stack-buffer-overflow on= address 0x7f6ca3efb480 at pc 0x7f6ca7162b61 bp 0x7f6ca3efb450 sp 0x7f6ca3e= fac00
> > WRITE of size 24 at 0x7f6ca3efb480 thread T-1
> > #0 0x7f6ca7162b60 in __interceptor_sigaltstack.part.0 (/lib64/lib= asan.so.8+0x61b60)
> > #1 0x7f6ca71d9337 in __sanitizer::UnsetAlternateSignalStack() (/l= ib64/libasan.so.8+0xd8337)
> > #2 0x7f6ca71c90f4 in __asan::AsanThread::Destroy() (/lib64/libasa= n.so.8+0xc80f4)
> > #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 o= f size 0x000000000018.
> > SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/libasan.= so.8+0x61b60) 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&n= bsp;
> > =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 byte= s):
> > 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 detect other memory leaks but it does not work. I get memo= ry 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 leake= d intentionally ... no difference what so ever .... I tried the same with t= he helloworld example and I get the same results .... 
>
> 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.
>

Looks like the alternate signal stack allocated inside address sanitizer is= not big enough.
--_000_AM0PR04MB66927D96934577B30C800F12D9B19AM0PR04MB6692eurp_--