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 A2ABB45BA0; Tue, 22 Oct 2024 14:41:32 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6FB1A4029A; Tue, 22 Oct 2024 14:41:32 +0200 (CEST) Received: from smtp-gw.pt.net (smtp-gw.pt.net [206.210.192.15]) by mails.dpdk.org (Postfix) with ESMTP id 4890840273 for ; Tue, 22 Oct 2024 14:41:30 +0200 (CEST) X-ASG-Debug-ID: 1729600889-09411a490e2cce30001-TfluYd Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by smtp-gw.pt.net with ESMTP id zr8QZbBKwuOiEN9s (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 22 Oct 2024 07:41:29 -0500 (CDT) X-Barracuda-Envelope-From: lew@perftech.com X-Barracuda-Effective-Source-IP: mail.pt.net[206.210.194.11] X-Barracuda-Apparent-Source-IP: 206.210.194.11 Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 3EE3BD0DAE6 for ; Tue, 22 Oct 2024 07:41:29 -0500 (CDT) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavis, port 10032) with ESMTP id de_N2FD-76vM for ; Tue, 22 Oct 2024 07:41:29 -0500 (CDT) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 11FD2D0DC37 for ; Tue, 22 Oct 2024 07:41:29 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.pt.net 11FD2D0DC37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perftech.com; s=B15A3A56-ABEA-11EE-9719-5F12F125680F; t=1729600889; bh=s/X+r3z0qCQjLATnvJnhJRapkaum3ChM1IygK1zwJeQ=; h=Date:From:To:Message-ID:MIME-Version; b=VWImT5omMyuXFyWV9eeZn2f9Ht0NPsFSBummE/3EGsALSQVcvUy3D0yNmEg9/oUyK V9YXS04W7gZz/8fndPg5ZL6FCC99Ta7pmA8vndfqtareeRu9hN9LZnkIg7FvEs6ijL ZZM9C+P40gZQ6IU88EnIrKM07uQenhf6x2We1JF+vbeWdkG8mVtF1Lb0MG30jkJ6tM IxgRcI9an/hI7oyNl1E+w3pRf+tDXz2H4GYX8fcnIldHEO+WjklyYIGcdcQlClXuH5 swVvjk43PZ6pgoh+OgbOtieycntXl93O+8xNsVrUjd04Womzjjp0RMTpGGDoiJPfhZ XZy7yaL5FRJ/w== X-Virus-Scanned: amavis at pt.net Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavis, port 10026) with ESMTP id B0DImcfVRyb7 for ; Tue, 22 Oct 2024 07:41:29 -0500 (CDT) Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by mail.pt.net (Postfix) with ESMTP id 01B20D0DAE5 for ; Tue, 22 Oct 2024 07:41:29 -0500 (CDT) Date: Tue, 22 Oct 2024 07:41:28 -0500 (CDT) From: Lewis Donzis To: dev Message-ID: <402897283.8962444.1729600888805.JavaMail.zimbra@donzis.com> Subject: Including contigmem in core dumps MIME-Version: 1.0 X-ASG-Orig-Subj: Including contigmem in core dumps Content-Type: multipart/alternative; boundary="=_ef85bc75-793b-4d19-a98e-38caf90ae277" X-Originating-IP: [206.210.194.11] X-Mailer: Zimbra 8.8.15_GA_4652 (ZimbraWebClient - GC130 (Mac)/8.8.15_GA_4652) Thread-Index: DmbFYBbQDGtvMU/Twh4udEW+j9sDsg== Thread-Topic: Including contigmem in core dumps X-Barracuda-Connect: mail.pt.net[206.210.194.11] X-Barracuda-Start-Time: 1729600889 X-Barracuda-Encrypted: TLS_AES_256_GCM_SHA384 X-Barracuda-URL: https://smtp-gw.pt.net:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at pt.net X-Barracuda-Scan-Msg-Size: 1429 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.132141 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --=_ef85bc75-793b-4d19-a98e-38caf90ae277 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've been wondering why we exclude memory allocated by eal_get_virtual_area() from core dumps? (More specifically, it calls eal_mem_set_dump() to call madvise() to disable core dumps from the allocated region.) On many occasions, when debugging after a crash, it would have been very convenient to be able to see the contents of an mbuf or other object allocated in contigmem space. And we often avoid using the rte memory allocator just because of this. Is there any reason for this, or could it perhaps be a compile-time configuration option not to call madvise()? --=_ef85bc75-793b-4d19-a98e-38caf90ae277 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I've been wondering why we exclude memory allocated by eal_get_virtual_area() from core dumps?  (More specifically, it calls eal_mem_set_dump() to call madvise() to disable core dumps from the allocated region.)

On many occasions, when debugging after a crash, it would have been very convenient to be able to see the contents of an mbuf or other object allocated in contigmem space.  And we often avoid using the rte memory allocator just because of this.

Is there any reason for this, or could it perhaps be a compile-time configuration option not to call madvise()?

--=_ef85bc75-793b-4d19-a98e-38caf90ae277--