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 CDE3D440E1; Tue, 28 May 2024 02:34:47 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B9BFA402D2; Tue, 28 May 2024 02:34:47 +0200 (CEST) Received: from smtp-gw.pt.net (smtp-gw.pt.net [206.210.192.15]) by mails.dpdk.org (Postfix) with ESMTP id 670714026F for ; Tue, 28 May 2024 02:34:46 +0200 (CEST) X-ASG-Debug-ID: 1716856484-09411a0f033a6da0001-TfluYd Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by smtp-gw.pt.net with ESMTP id VR4NzKaYeAscHMAd (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 27 May 2024 19:34:44 -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 8A7511D376CB for ; Mon, 27 May 2024 19:34:44 -0500 (CDT) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavis, port 10032) with ESMTP id GlH1dYsHVip6 for ; Mon, 27 May 2024 19:34:44 -0500 (CDT) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 623D91D376CA for ; Mon, 27 May 2024 19:34:44 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.pt.net 623D91D376CA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perftech.com; s=B15A3A56-ABEA-11EE-9719-5F12F125680F; t=1716856484; bh=YNh/8PCnS1wzLFJ9FetLo7nX7TmyrvYIVfjHDodValg=; h=Date:From:To:Message-ID:MIME-Version; b=R3E3v0tw6j8/1S+oxfyFtNHGCy30qDdGT/nUul5W4gUQ03hGRttG+RDJEl2hzhLJe 0r0pb0YW6SvI4fYqROsh8CUnegYVdi96YjkU6spB0qen4Q5g5p+VAvigGhqZLv+m3D HjPN3Vm8zz3UnprSvKJE7oqJ94ce3gL7ZarrwFavc3i8c0CLoVDMiCxBIw7t8Ps55n Eil22g/s37QX/P80vIdrxsUc6oP2fqOVsSDaHgNd9Z47x87yW8ytD//TDLBF0rUhyo 2BBXJr3Dp35wqweZbOyC60eWxpHV+4ecTiwowElhX7pP2jn8T6LZhF2M2OBlevc8xK 9jn5FOpPU/yWg== 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 DZoCHhKDkrx2 for ; Mon, 27 May 2024 19:34:44 -0500 (CDT) Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by mail.pt.net (Postfix) with ESMTP id 5420C1D376C3 for ; Mon, 27 May 2024 19:34:44 -0500 (CDT) Date: Mon, 27 May 2024 19:34:44 -0500 (CDT) From: Lewis Donzis To: dev Message-ID: <1771016800.166016.1716856484319.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="=_9c2601d1-728a-4c75-a7b0-2fdd3be0cf62" X-Originating-IP: [206.210.194.11] X-Mailer: Zimbra 8.8.15_GA_4581 (ZimbraWebClient - GC125 (Mac)/8.8.15_GA_4581) Thread-Index: yynUUWiOvU6pR4dUdftxtzMpsSSqyw== Thread-Topic: Including contigmem in core dumps X-Barracuda-Connect: mail.pt.net[206.210.194.11] X-Barracuda-Start-Time: 1716856484 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: 1348 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.125437 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 --=_9c2601d1-728a-4c75-a7b0-2fdd3be0cf62 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()? --=_9c2601d1-728a-4c75-a7b0-2fdd3be0cf62 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()?
--=_9c2601d1-728a-4c75-a7b0-2fdd3be0cf62--