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 DAB32A0032 for ; Fri, 17 Jun 2022 06:08:18 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6448140698; Fri, 17 Jun 2022 06:08:18 +0200 (CEST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-oln040092073083.outbound.protection.outlook.com [40.92.73.83]) by mails.dpdk.org (Postfix) with ESMTP id 10BF740689 for ; Fri, 17 Jun 2022 06:08:17 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=akOH+QyFR9lkveS8aVfxgNOaB8waVOSTuyGTYPVL+Zj/gmGIOni7x1Aj9mL2ZtU3LGzUloPOIVqOsfeaMxrtAivhDq5J/qVS+NRa57COglavF2R4+KtSGgpOGleojiKN9w7dZrVf7Uje73eCgK3LrM+C21nW+upZnauKDJ8NSzEcbzqOGgHrZWLmG5wQRpfbiGov/Rf+g3OC7Y0HN8eDaaZsXu2GJ+3mKZ+3bzAVNf4dKqqprTW9qm+Kgb5ho9YiIbaJ6KG8JqpKrezMALQ17m7yFMC9t0PYpprPFcv+0DyqQEaX2N4m3zOyf+IJiml7coYd6if3upekCaTtgiGqLg== 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=wlS2QMngvFSIzgz4/JcUYKgZU+3y+WsJUrVzhx+1jpE=; b=EqgUaMCK4mfFyd8K+bPwNr4USSGGoyqeTcVBpRfNE1tcWSTS8+6jrs7omz2b/QrzcmGpm6R86Rh3jt/GImJc8VnwpcMkwggpwzGVZT7OWwejUsQYtSMTZI6SMWXJ7tOGGolYLbQ+3xpJUp+lh13BZ54KjO8CqEFoAmQDMcXRH3FxMqBWv+SWC9/YeE7bboKSbu/0/Bbq11tYpx/0G6aGL9g2P63jTiTmN3HnX+NEUopY15BEDbqf3kOKeL3PvZeVIjdWDWdNpqG7zHWMJ1ReuabrTYvJ77bqAPVQmDTv++BeSk33nfX1q0pebYmBwuEaJB4zT6NawDmhep9VypqVLw== 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=wlS2QMngvFSIzgz4/JcUYKgZU+3y+WsJUrVzhx+1jpE=; b=Wq6EbArRGzOqbXiNwsjQNYCBa3Xr7mIcknMPkJq+x468LJZzWQu2EwjHlapVArlj2D9YoSHd7+ulpI5G/FA2Wy3QL2cANJWYABwvWUj9Z2sssuolY72fR4SVwxRMJ8gedbDybpfJvz6WL8YZAIhudGc+fhdxj9nI4BK/rkLJ+F23SyLWkA+hRflppOMih6SYBhAOCvn20tJvbSo13g4wZUniriqsWSE6cVZZ4gFHXZ8ARcBTSjHLu6/Y7uVzTSOZwAzTmoMQBjW3wcUWNyMbVsJNG2Q/3+Cdp09zTHn9Sw2OIow7AexPDxlRYq3akZjbW4CGY7izYVTndXp3l7qsUw== Received: from AM0PR04MB6692.eurprd04.prod.outlook.com (2603:10a6:208:178::25) by VI1PR04MB7104.eurprd04.prod.outlook.com (2603:10a6:800:126::9) 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 04:08:15 +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.014; Fri, 17 Jun 2022 04:08:15 +0000 From: Juan Pablo L. To: "users@dpdk.org" Subject: dpdk address sanitizer Thread-Topic: dpdk address sanitizer Thread-Index: AQHYgf7T2wIwZUgikkik372p4IwcSQ== Date: Fri, 17 Jun 2022 04:08:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: cb55dacb-4784-e2f5-8530-ec846f6f6c23 x-tmn: [YFgyd8t2fC5uGg1LhlvBghLxda7Im0Xi] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0ec1e448-b110-4816-83dd-08da501700e0 x-ms-traffictypediagnostic: VI1PR04MB7104:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KSEqV4XXouP6pYo/AGouLLlyMTQWKIfs0kgSiIQJhNtF7fqM5wfqFlePGQ1Tvc55N6ysteMmr6foq7AgqoyPkUPpNwapl+A6KFnIuiqUN5HxkGe2NobcBUydY6t0w8ASyhZafnk4eXirpTctDNeH6Ukb67K9iVqS4jKfxYwv0MBnMT2IfYBRcOPDhiJ9WrcshbYTflIB8tB2dQzBKf4WPWyeHnQmxfBmgYsgCvDf8kd6k6wULQvdYpnmIwFtufnUOf7WYPozv6l+rfAP+m51aNxMQmyGB07B4cFyDTGKlZf1YqvQrwQp+i21zts5E6Wx/bmfyqVwain1sPVaQmCehoLT9wRP9QXxXzinh2o1z4nrQDmD60bT6qM2eQFifxKUrPa5/XV5pUzO33vVUmH6NrFI2T0CchIeCMpkGMX1SSPA2TYR6NULmdL2Vj5riWAFwki1ZSygQNRF9psCAxEujXnoGlqfSJ7F5F3afDNBzDBXCvi+ktdiRSrZl1UmidLXcxUTDYajxIBW5ArMGQK3nNoVXQazS/RQIxVeeL7A4lbfVKGTt9CSNRA0bV3K0/5shn7W3hSv7n7mhIwU+bK6YQ== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?uBjR6vq1xGXpKtQvuHDjAgjlbZI02Fnp9iCbg4Pe8nAHppP/ty8J0h2d0q?= =?iso-8859-1?Q?v1srdQe6SUiQ2vU/cyc50+N+xhLvGAbZBg3JUeGe0sVmW3V9+fWB9ND/XA?= =?iso-8859-1?Q?MXvnbTD5DT8bwIJyAEkiVcfNowDKALJE52plkEO8QcST71buxIJg2xjUVC?= =?iso-8859-1?Q?lxy4Pphd4yvSoh2M7NunOfTD5mHeKvVeWOKaHTKYq2SXgF+VfgWv6Tgx82?= =?iso-8859-1?Q?3n4RDWnNrjKZK4bZKbstDBLrqvifT5E+VfDO4htgTctkny1vLoHWPBlXe2?= =?iso-8859-1?Q?JkRpNx9NrLoBCO807RNY3FmMjpeciUX7x4wogxMDDJnE3ewGO9CeRmh2GJ?= =?iso-8859-1?Q?zd4b9SUeAsdoKmN1oSNCiMp0kTohF+CTXTlS68EYt40fBTIwewta3ELZId?= =?iso-8859-1?Q?X0AIFINkmfdbd8tQR8znub3V17iS1ASNHibPySSoZTi0fJxnHWbGs/OQeY?= =?iso-8859-1?Q?W8EjdhBRXz63ab0pbJEaWDwZXU0osMat0oGJ4NAaXJpCJ1Xob2Wq//42RD?= =?iso-8859-1?Q?Oacs215ot6yDcS1+u9jLigT1TAhq4jcRb5hp+aKvGTJscPY1f3yBHFPA3c?= =?iso-8859-1?Q?yBzBKAIrSxX+V+ixGFQ0Cp3cL966MKC5bxzanZApKNK+PhegWdnd9lfXSY?= =?iso-8859-1?Q?781UFla8BI2KKbVkjlllrtGhfEcv5PQ2/BQa65in0ZOuHhkg4EEo2bf746?= =?iso-8859-1?Q?1tpW4UORj3dO2jaOJBAH2LC/seOVYjZqQoPyYwfXV8Gk41pcQvpWQRJe3Z?= =?iso-8859-1?Q?6xronRyeDBgIGlZqw3kqK9svIxU235Nsh7MMJFpAeQADweGMZNd35slObQ?= =?iso-8859-1?Q?nycglqoDOYVgGHFLziZZi55ccfv01LTP390KXHvdfs8Id5OTrY73XVmwLq?= =?iso-8859-1?Q?B29G5WRIjuaOg9umEyW0yoaZuY7/vBi+PTB5SNRnGgeg7ozRFZPsb/e75R?= =?iso-8859-1?Q?Z0FtDKeWRtjOCc6tCR0MPPUnxIh3iF1JPW9LAoKy0gULwIguL6jWOgdi40?= =?iso-8859-1?Q?tHNQwUU15ocoBQnTPN8kByLKaE/g86vb6kf1i50p5HUwXa50hUaJtVSZdX?= =?iso-8859-1?Q?gA3SORqsN3ayQd5Az9ByN1f6VFMvO7h5x8gpP/aQWkxO7gVzo98fviOuyx?= =?iso-8859-1?Q?VHIXmnnkAG9e5v8cCMf57OhmaqsK1b1e6MP+AzZJgq2o/5Baqd8WJ8z911?= =?iso-8859-1?Q?cQ+TBbFTU9Aw02Nt8ipSmWImHNmqlTYosXTK0D0Ct8R3PHXu05smpxTWU2?= =?iso-8859-1?Q?aUez6Vt5DNRJqDHwN39UrA4LdjiZ98Z9leB8yZO+jQ6SlaV5B/h0VPa+Ak?= =?iso-8859-1?Q?ql1Ts8utqSL5/lRYbphSVi+b2NJA/tLouZmxyrdK3ehcAcIresKnXbijsz?= =?iso-8859-1?Q?UtvnQyibFFjmzO9iDQCKH09OQUEfK6fg77bC0vIXKw4xXVOoMyhJgYxDv7?= =?iso-8859-1?Q?HeHtI0oImI1Tw9jK7USshbkK9iP/QTLqVgbs6g5gl4TzYiz4uU8iuRrIzI?= =?iso-8859-1?Q?0=3D?= Content-Type: multipart/alternative; boundary="_000_AM0PR04MB66929C6A4ECBCAC57C8C9C87D9AF9AM0PR04MB6692eurp_" 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: 0ec1e448-b110-4816-83dd-08da501700e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2022 04:08:15.5061 (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: VI1PR04MB7104 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 --_000_AM0PR04MB66929C6A4ECBCAC57C8C9C87D9AF9AM0PR04MB6692eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I am new to dpdk ... i would like to trace memory usage and detect m= emory leaks, valgrind as well as address sanitizer (gcc) report some 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 0= x7f6ca3efb480 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/libas= an.so.8+0xd8337) #2 0x7f6ca71c90f4 in __asan::AsanThread::Destroy() (/lib64/libasan.so.8+0xc= 80f4) #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 0x0= 00000000018. SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/libasan.so.8+0x61b= 60) 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 th= at, I try other scenarios and see if I can just "ignore" that and still det= ect other memory leaks but it does not work. I get memory from rte_malloc a= nd don't free it and I still get the above report only, I do not get any re= port from the memory I leaked intentionally ... no difference what so ever = .... I tried the same with the helloworld example and I get the same result= s .... Please, if anyone can shed some light and point me in any direction ... I h= ave already searched google for 2 days with nothing new ... surely, I m doi= ng something wrong but I believe I have read everything I can find on googl= e related to tracing memory in dpdk and there is very little information ab= out it and mostly dismiss valgrind and favor the address sanitizer ... specs: Fedora 36 server edition (KVM vm) gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1) dpdk 22.03 (compiled with: -Dbuildtype=3Ddebug -Dprefix=3D/path/to/lib/dpdk= -22.03/debug/ -Dtests=3Dfalse -Denable_kmods=3Dtrue -Denable_trace_fp=3Dtru= e -Db_sanitize=3Daddress) thank you very much! --_000_AM0PR04MB66929C6A4ECBCAC57C8C9C87D9AF9AM0PR04MB6692eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello, I am new to dpdk ... i would li= ke to trace memory usage and detect memory leaks, valgrind as well as addre= ss sanitizer (gcc) report some 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 sa= me results):


=3D=3D3399=3D=3DERROR: AddressSanitize= r: stack-buffer-overflow on address 0x7f6ca3efb480 at pc 0x7f6ca7162b61 bp = 0x7f6ca3efb450 sp 0x7f6ca3efac00

WRITE of size 24 at 0x7f6ca3efb480 thr= ead T-1

#0 0x7f6ca7162b60 in __interceptor_sig= altstack.part.0 (/lib64/libasan.so.8+0x61b60)

#1 0x7f6ca71d9337 in __sanitizer::Unse= tAlternateSignalStack() (/lib64/libasan.so.8+0xd8337)

#2 0x7f6ca71c90f4 in __asan::AsanThrea= d::Destroy() (/lib64/libasan.so.8+0xc80f4)

#3 0x7f6ca679b000 in __GI___nptl_deall= ocate_tsd (/lib64/libc.so.6+0x8a000)

#4 0x7f6ca679dc9d in start_thread (/li= b64/libc.so.6+0x8cc9d)

#5 0x7f6ca68235df in __GI___clone3 (/l= ib64/libc.so.6+0x1125df)


Address 0x7f6ca3efb480 is a wild point= er inside of access range of size 0x000000000018.

SUMMARY: AddressSanitizer: stack-buffe= r-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 0= 0 f1 f1 f1 f1 00 00 00 00

0x0fee147d7650: 00 00 00 00 00 00 00 0= 0 00 06 f2 f2 f2 f2 00 00

0x0fee147d7660: 00 00 00 00 00 00 00 0= 0 00 00 00 00 00 00 00 00

0x0fee147d7670: 00 00 00 00 00 00 00 0= 0 00 00 00 00 00 00 00 00

0x0fee147d7680: 00 00 00 00 00 00 00 0= 0 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 0= 0 00 00 00 00 00 00 00 00

0x0fee147d76b0: 00 00 00 00 00 00 00 0= 0 00 00 00 00 00 00 00 00

0x0fee147d76c0: 00 00 00 00 00 00 00 0= 0 00 00 00 00 00 00 00 00

0x0fee147d76d0: 00 00 00 00 00 00 00 0= 0 00 00 00 00 00 00 00 00

0x0fee147d76e0: 00 00 00 00 00 00 00 0= 0 00 00 00 00 00 00 00 00

Shadow byte legend (one shadow byte re= presents 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 detect other memory leaks but i= t 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 ....


Please, if anyone can shed some light = and point me in any direction ... I have already searched google for 2 days= with nothing new ... surely, I m doing something wrong but I believe I hav= e read everything I can find on google related to tracing memory in dpdk and there is very little information abo= ut it and mostly dismiss valgrind and favor the address sanitizer ...


specs:

Fedora 36 server edition (KVM vm)

gcc (GCC) 12.1.1 20220507 (Red Hat 12.= 1.1-1)

dpdk 22.03 (compiled with: -Dbuildtype= =3Ddebug -Dprefix=3D/path/to/lib/dpdk-22.03/debug/ -Dtests=3Dfalse -Denable= _kmods=3Dtrue -Denable_trace_fp=3Dtrue -Db_sanitize=3Daddress)


thank you very much!
--_000_AM0PR04MB66929C6A4ECBCAC57C8C9C87D9AF9AM0PR04MB6692eurp_--