From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 06043A0032; Fri, 17 Jun 2022 23:24:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9C5AE40F19; Fri, 17 Jun 2022 23:24:55 +0200 (CEST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-oln040092075026.outbound.protection.outlook.com [40.92.75.26]) by mails.dpdk.org (Postfix) with ESMTP id 6AF5740E2D; Fri, 17 Jun 2022 23:24:54 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gHBnQhhxC+Lm5+/ybkjrS4clLtCepsgvMszGNuwu1uYqiPnaq6YI6oq308asJMuOdQUzZvhtLpZOc25Y98tVWXqEqW30QkQAgU8s6RRqPvxjMMp/MujvFXKUFP03EgoZjg44r5Y3sajq8InWTqQXFedUWUBXrmA2/fTNOFiajYDWC7JrIzPKuTxvW5P//UFGSJTtcVqdsdfzgQSASggMqcrqX8ICVCE2AoVJ/cGI1nCU9gIjNgVL9kf2gUcre6bwC+ejbVi7+y1sYaaGvTlU7F/GbWIdBIBeYgZs9LYHqToDOinfwpJFzdpbdLHoyr/GCui9MLwa0eZWnHz8eEB3HA== 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=z3jXyDtu9cmO8uVwP0lIc92wPfZspi9ZhvtUqGhrZug=; b=mEV9eeFjFCfPKCcs7lhJVisX7kwxexEkbiVtgQ2O7ykETjyDBTOLZzgm630PJCTyu6DSYFmnirp6z1hctrwAnqeauEO3uva1N34+vu6qivfrIcMmQdloLGGrzvSvmzPpOHmbHrS1/jQak6PTVPKVvB54vSR2/EBDeElwCCrkLzc26N5T5TPqFf0pfLOT+ZqMXzifZOyxn5BEQQx3WQXRl0rOx0JhShS5h203M1G4O/rE/noViUkYZ94W8xZ59Mhge5WqNdhDf1O1XD0hZbc2F2q7juspSukGBtrZTacBRXUKVQrwwsUZ8MjShRMDOTqbi7MMif02tS5BOecX6WtEWg== 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=z3jXyDtu9cmO8uVwP0lIc92wPfZspi9ZhvtUqGhrZug=; b=K4SwS0OPflB2uw0Q1WmzY6OvV1o/xR/kHd0Yir4rkrtpkf99s8RO/UpNioPXBE/G30rPxobDA6xPRIm1cjTjmTO+dcts5wXve8RFkM3LXCc6FoXmtTRhqVqLHJmr5x0PVMw7PitaN2/d4noyjWqLmBhCj+h7vcEHFVKSJ06A6Aj2MEWCvaGS7WcSSRNiB6c8owPJGFMP26qaSof8Cn4R5QGwhbv1LUe5+FPglaJ3di8RWwPtjQjzdmrP7Y/qQ42bOUWMtsLTLTmuSeEPibxDR0RGgb+RrJqQq4LGV558G8X1K2qUF/3wf1qGixYuebsvzPK1StHHtxD2TC3xzoU4Ig== Received: from AM0PR04MB6692.eurprd04.prod.outlook.com (2603:10a6:208:178::25) by AM6PR04MB4710.eurprd04.prod.outlook.com (2603:10a6:20b:3::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.16; Fri, 17 Jun 2022 21:24:53 +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.018; Fri, 17 Jun 2022 21:24:53 +0000 From: Juan Pablo L. <jpablolorenzetti@hotmail.com> To: David Marchand <david.marchand@redhat.com> CC: "users@dpdk.org" <users@dpdk.org>, "Burakov, Anatoly" <anatoly.burakov@intel.com>, Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>, dev <dev@dpdk.org>, "ci@dpdk.org" <ci@dpdk.org> Subject: Re: dpdk address sanitizer Thread-Topic: dpdk address sanitizer Thread-Index: AQHYgf7T2wIwZUgikkik372p4IwcSa1TFu2AgAEGScw= Date: Fri, 17 Jun 2022 21:24:53 +0000 Message-ID: <AM0PR04MB6692C4BFEFB03345942FE5E7D9AF9@AM0PR04MB6692.eurprd04.prod.outlook.com> References: <AM0PR04MB66929C6A4ECBCAC57C8C9C87D9AF9@AM0PR04MB6692.eurprd04.prod.outlook.com> <CAJFAV8xMkHtQfeAX6HFBH+5Ddjnr_L-fmv0fUoM+i_fTLTnFDw@mail.gmail.com> In-Reply-To: <CAJFAV8xMkHtQfeAX6HFBH+5Ddjnr_L-fmv0fUoM+i_fTLTnFDw@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [7X1sh4rwKDwG2ovdB2c226KwJs9PJhha] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f6b06a0b-70b8-4fe1-b4ad-08da50a7d192 x-ms-traffictypediagnostic: AM6PR04MB4710:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XYz3iU39Gdqpp1Py1v2Ev3m8YiVOl8iBwWj2++uVPXF/zRPXhUQdoWX76IeJWm9G6KEgUpQtMIj3m5iNHJgw1UJ/muOXiC3Y7m/PZHiiel8IRiOigJ2VndvaCYyE0Mdv99Bymd+wtDeAXYmtBqvfqbxlZy2bDVpSFhBB7dLUCPrHVx5y7hc7+2+PxQiTh61hbvrhJKbckVcSVTRe8hSipUCD9fD8EO2urbNgicV4qHtKNdWhBh/8GGVwvNcPAfmyJ+XcLsbx4XrcIJYfcUd/HedhXXETtQoAfWA3+WhxxHG+eF/3KaGQNCmeu+QRxOKNpdkV2bdhZPzNZO5XOvohpxozI6F4j8m9yvWon6BfpggluzNyxciZbPR7ilS3FceuRbAwASANelPDd/itvwPQEI0bk5B6r3tv7RRKscMCmPu/wW0gI8dMa4BHBfzYxa32Qgj6nV6owasjMkzc5IG3RTKCle+0L8D9eeMUmHoy49RP8sKRqWxyIFEUfca0ZxqjIs2IAiB2P1Ua3gWYEs0g7lQaMKtqoHBNTMi80noEjrjBeEGcVlX+eLnZBJUAHJ8of2g0r0V0Q62p22vKkUNytRZGBOSYVLAcWQKjv94/X0S3DfuaO6guLKx+4bekZB2z x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?SpPBuwGi7B5H/1SeoqHa8C0IvURhk6voCVjJCc7OoFH0JlBVk+IV8LRk/hd+?= =?us-ascii?Q?mI+qZXO3jskTWJJKoSXt0HR2p0Xlxy+nwOOFi4cgMx638OUcpoasULK+27q9?= =?us-ascii?Q?VbwxVaVTSmsPxXGWlJ2eOZh+5Cow/05lYBjfuJqyJ4mY1EkUDIdeKPG7FXvB?= =?us-ascii?Q?niMyRA6KiOwNThjhy+d08BeB3N8GLsPLx12Vhf2sg5t6wdWNdtGQzKpNe9nV?= =?us-ascii?Q?xOPku9TCl6HcFV1BHHWcsBWQqCpP1uo/sfkT6SUqZVf7enjoCzgIGjxbZKS8?= =?us-ascii?Q?JWyQ+w293s4JtFOY1v3k3lxQsI2JtwnDRPhjVe2bhNa3y82XpXLE3IDuwYWw?= =?us-ascii?Q?R0xQMCHNYLBRjqZbD8c3Oee6YlrSo5Ad4bp21+ZQkepnzU2X+bTrxO5y9W/y?= =?us-ascii?Q?m62qEmLo5412eg9YEx+dLn776JgeKB6xqfCPfSm0z5BR+ZeVQXeBqvdeSoDe?= =?us-ascii?Q?CpWI/PcFocNTX9RAmeg7wjOasJHor+2JUo7XxPGGRLiB54EPHQzZESHo4ZRu?= =?us-ascii?Q?8wA/k+jRAJUkoHb7lv/CZxfQRB1xYWicfgJZwxzDUrCJ7gz4/GCGvMwsXEth?= =?us-ascii?Q?no+BpNTKDqgRYvN8p8AV9NOKsKiVwdFPB3C9IolTpzKvcq/WHXvlJMkCKp3f?= =?us-ascii?Q?yNeNL82PZtJ3w+wHPC8bKjmZpAAiXyVbLohXVhpb7BqljFoycRBYYP5G46/G?= =?us-ascii?Q?DL3hyJzUHf1gGh2w+HXszKBz77TJPWWOgO9gkFgQucw69A0tIPMlGTtf/gIH?= =?us-ascii?Q?KAn3+d4GwZwLMuvimBnKoGuqkfHd5yf6DlIicrmZTm14NGvJ6dOiMWISI80Y?= =?us-ascii?Q?Lbrq2L/Icq+2L+uGo6fePUKhDQ0pTBXEDEAQzqfvGko9IHb4me55pwgyN8L/?= =?us-ascii?Q?Nb8WKCWYUFRtrMu1uZO3rAKHGC1K6bDNafObk43ODJOVCD9hgtzFy3A0Z6Zp?= =?us-ascii?Q?UZyZ8jWq3Ney3iwVC70q8kvhLB543uzEhsZIWRP0E1w4JXbulNMK2ryB3vVC?= =?us-ascii?Q?NwJO185iXWIKMuqNFtsUKrDGxItubCQ0C6IOCS+dO+wUh1jAPfMsKBCN+B3u?= =?us-ascii?Q?KUa7gOmJZtBGZeTsdcZA7gnGaSqbHMXwkx+KZCavalSmRK0Lipfy9dVooBcj?= =?us-ascii?Q?yfAXV39uUWr0UPhU262yvOp65PgBrq6HxWjS8XCDDQNyxwVtHyHI+z39lS26?= =?us-ascii?Q?pHAzbauAiGeySL2fS7EMGaTYSYEPS25cw9QT3PsEkAg8lzIvIGl/57t3Ft3I?= =?us-ascii?Q?/sMMT5bUXXn5GL6HbQHqKKuKnrrqYdTgHkEmZBPT+1w6ysUmp6lXIi1awtjZ?= =?us-ascii?Q?TwHHR++G+qT1CBj8tbay1apNuqQHU5/UP1yU4ki2YYIbLC3qKx/q0fg8lx7p?= =?us-ascii?Q?iP5Xqd9DVvx6Ji3Is9SH3Jz9F6C5626JtRxvFXia7pYdDydUXD0Bj6cnbfpi?= =?us-ascii?Q?kYeHdCp5oLTKhwUYfqcHNuE4/aV3sFSv?= Content-Type: multipart/alternative; boundary="_000_AM0PR04MB6692C4BFEFB03345942FE5E7D9AF9AM0PR04MB6692eurp_" 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: f6b06a0b-70b8-4fe1-b4ad-08da50a7d192 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2022 21:24:53.1534 (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: AM6PR04MB4710 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org --_000_AM0PR04MB6692C4BFEFB03345942FE5E7D9AF9AM0PR04MB6692eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you very much, I will try that. Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: David Marchand <david.marchand@redhat.com> Sent: Thursday, June 16, 2022 11:45:33 PM To: Juan Pablo L. <jpablolorenzetti@hotmail.com> Cc: users@dpdk.org <users@dpdk.org>; Burakov, Anatoly <anatoly.burakov@inte= l.com>; Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>; dev <dev@dpdk.org>; ci@d= pdk.org <ci@dpdk.org> Subject: Re: dpdk address sanitizer 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 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. -- David Marchand --_000_AM0PR04MB6692C4BFEFB03345942FE5E7D9AF9AM0PR04MB6692eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body> <div style=3D"color: rgb(33, 33, 33); background-color: rgb(255, 255, 255);= " dir=3D"auto"> Thank you very<span> much, I will try that. </span></div> <div id=3D"ms-outlook-mobile-signature" dir=3D"auto"> <div><br> </div> Get <a href=3D"https://aka.ms/AAb9ysg">Outlook for Android</a></div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> David Marchand <da= vid.marchand@redhat.com><br> <b>Sent:</b> Thursday, June 16, 2022 11:45:33 PM<br> <b>To:</b> Juan Pablo L. <jpablolorenzetti@hotmail.com><br> <b>Cc:</b> users@dpdk.org <users@dpdk.org>; Burakov, Anatoly <anat= oly.burakov@intel.com>; Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>;= dev <dev@dpdk.org>; ci@dpdk.org <ci@dpdk.org><br> <b>Subject:</b> Re: dpdk address sanitizer</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">Hello,<br> <br> On Fri, Jun 17, 2022 at 6:08 AM Juan Pablo L.<br> <jpablolorenzetti@hotmail.com> wrote:<br> ><br> > Hello, I am new to dpdk ... i would like to trace memory usage and det= ect memory leaks, valgrind as well as address sanitizer (gcc) report some m= emory 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):<br> ><br> > =3D=3D3399=3D=3DERROR: AddressSanitizer: stack-buffer-overflow on addr= ess 0x7f6ca3efb480 at pc 0x7f6ca7162b61 bp 0x7f6ca3efb450 sp 0x7f6ca3efac00= <br> > WRITE of size 24 at 0x7f6ca3efb480 thread T-1<br> > #0 0x7f6ca7162b60 in __interceptor_sigaltstack.part.0 (/lib64/libasan.= so.8+0x61b60)<br> > #1 0x7f6ca71d9337 in __sanitizer::UnsetAlternateSignalStack() (/lib64/= libasan.so.8+0xd8337)<br> > #2 0x7f6ca71c90f4 in __asan::AsanThread::Destroy() (/lib64/libasan.so.= 8+0xc80f4)<br> > #3 0x7f6ca679b000 in __GI___nptl_deallocate_tsd (/lib64/libc.so.6+0x8a= 000)<br> > #4 0x7f6ca679dc9d in start_thread (/lib64/libc.so.6+0x8cc9d)<br> > #5 0x7f6ca68235df in __GI___clone3 (/lib64/libc.so.6+0x1125df)<br> ><br> > Address 0x7f6ca3efb480 is a wild pointer inside of access range of siz= e 0x000000000018.<br> > SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/libasan.so.8+= 0x61b60) in __interceptor_sigaltstack.part.0<br> > Shadow bytes around the buggy address:<br> > 0x0fee147d7640: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00<br> > 0x0fee147d7650: 00 00 00 00 00 00 00 00 00 06 f2 f2 f2 f2 00 00<br> > 0x0fee147d7660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br> > 0x0fee147d7670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br> > 0x0fee147d7680: 00 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3<br> > =3D>0x0fee147d7690:[f3]f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00= <br> > 0x0fee147d76a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br> > 0x0fee147d76b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br> > 0x0fee147d76c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br> > 0x0fee147d76d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br> > 0x0fee147d76e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br> > Shadow byte legend (one shadow byte represents 8 application bytes):<b= r> > Addressable: 00<br> > Partially addressable: 01 02 03 04 05 06 07<br> > Heap left redzone: fa<br> > Freed heap region: fd<br> > Stack left redzone: f1<br> > Stack mid redzone: f2<br> > Stack right redzone: f3<br> > Stack after return: f5<br> > Stack use after scope: f8<br> > Global redzone: f9<br> > Global init order: f6<br> > Poisoned by user: f7<br> > Container overflow: fc<br> > Array cookie: ac<br> > Intra object redzone: bb<br> > ASan internal: fe<br> > Left alloca redzone: ca<br> > Right alloca redzone: cb<br> > =3D=3D3399=3D=3DABORTING<br> ><br> > 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" tha= t and still detect other memory leaks but it does not work. I get memory fr= om 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 in= tentionally ... no difference what so ever .... I tried the same with the h= elloworld example and I get the same results ....<br> <br> I experienced the same issue recently on Fedora 36.<br> I did not investigate.<br> <br> I think I waived this warning, by setting<br> ASAN_OPTIONS=3D"use_sigaltstack=3D0" in the environment.<br> HTH.<br> <br> -- <br> David Marchand<br> <br> </div> </span></font></div> </body> </html> --_000_AM0PR04MB6692C4BFEFB03345942FE5E7D9AF9AM0PR04MB6692eurp_--