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 88C09A0093 for ; 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 8171F41148; Fri, 17 Jun 2022 23:24:56 +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. To: 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: AQHYgf7T2wIwZUgikkik372p4IwcSa1TFu2AgAEGScw= Date: Fri, 17 Jun 2022 21:24:53 +0000 Message-ID: References: In-Reply-To: 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: 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_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 ________________________________ From: David Marchand Sent: Thursday, June 16, 2022 11:45:33 PM To: Juan Pablo L. Cc: users@dpdk.org ; Burakov, Anatoly ; Dmitry Kozlyuk ; dev ; ci@d= pdk.org Subject: Re: dpdk address sanitizer 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. -- David Marchand --_000_AM0PR04MB6692C4BFEFB03345942FE5E7D9AF9AM0PR04MB6692eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you very much, I will try that. 
From: David Marchand <da= vid.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 <anat= oly.burakov@intel.com>; Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>;= dev <dev@dpdk.org>; ci@dpdk.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 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):
>
> =3D=3D3399=3D=3DERROR: AddressSanitizer: stack-buffer-overflow on addr= ess 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/= libasan.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+0x8a= 000)
> #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 siz= e 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
> =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" 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 ....

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_--