From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74065 invoked by alias); 5 Mar 2015 15:48:35 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 74049 invoked by uid 89); 5 Mar 2015 15:48:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 05 Mar 2015 15:48:33 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t25FmVBB007292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 5 Mar 2015 10:48:32 -0500 Received: from host1.jankratochvil.net ([10.40.204.26]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t25FmRtc011792 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2015 10:48:30 -0500 Date: Thu, 05 Mar 2015 15:48:00 -0000 From: Jan Kratochvil To: Sergio Durigan Junior Cc: GDB Patches , Pedro Alves , Oleg Nesterov Subject: Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902) Message-ID: <20150305154827.GA9441@host1.jankratochvil.net> References: <878ufc9kau.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <878ufc9kau.fsf@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00156.txt.bz2 On Thu, 05 Mar 2015 04:48:09 +0100, Sergio Durigan Junior wrote: > bit 0 Dump anonymous private mappings. > bit 1 Dump anonymous shared mappings. > bit 2 Dump file-backed private mappings. > bit 3 Dump file-backed shared mappings. > bit 4 (since Linux 2.6.24) > Dump ELF headers. > bit 5 (since Linux 2.6.28) > Dump private huge pages. > bit 6 (since Linux 2.6.28) > Dump shared huge pages. [...] > The default value for this file, used by the Linux kernel, is 0x33, > which means that bits 0, 1 and 4 are enabled. This is also the default and 5 > for GDB implemented in this patch, FWIW. [...] > With Oleg's help, we could improve the current algorithm for determining > whether a memory mapping is anonymous/file-backed, private/shared. GDB > now also respects the MADV_DONTDUMP flag and does not dump the memory s/does not dump/does dump/ > mapping marked as so, and won't try to dump "[vsyscall]" or "[vdso]" > mappings as before (just like the Linux kernel). Currently it also tries to dump [vvar] (by default rules) but that is unreadable for some reason, causing: warning: Memory read failed for corefile section, 8192 bytes at 0x7ffff6ceb000. ^^^^^^^^^^^^^^ Saved corefile /tmp/1j (gdb) _ # grep 7ffff6ceb000 /proc/$p/maps 7ffff6ceb000-7ffff6ced000 r--p 00000000 00:00 0 [vvar] ^^^^^^^^^^^^ ^^^^ I do not know what [vvar] is good for and why it cannot be read. > It is worth mentioning that, from all those checks described above, > the most fragile is the one to see if the file name ends with " > (deleted)". This does not necessarily mean that the mapping is > anonymous, because the deleted file associated with the mapping may > have been a hard link to another file, for example. The Linux kernel > checks to see if "i_nlink == 0", but GDB cannot easily do this check. # stat /proc/21604/map_files/400000-4ec000 File: ‘/proc/21604/map_files/400000-4ec000’ -> ‘/tmp/bash-deleted’ Size: 64 Blocks: 0 IO Block: 1024 symbolic link Device: 3h/3d Inode: 1554082 Links: 1 # stat -L /proc/21604/map_files/400000-4ec000 File: ‘/proc/21604/map_files/400000-4ec000’ Size: 1051464 Blocks: 2056 IO Block: 4096 regular file Device: fd01h/64769d Inode: 5509691 Links: 1 # rm /tmp/bash-deleted # stat -L /proc/21604/map_files/400000-4ec000 File: ‘/proc/21604/map_files/400000-4ec000’ Size: 1051464 Blocks: 2056 IO Block: 4096 regular file Device: fd01h/64769d Inode: 5509691 Links: 0 ^ One could find if i_nlink == 0 if it would be enough. But it would work only if GDB runs as root so it is probably not worth coding it: $ ls -ld /proc/3803/map_files dr-x------ 2 lace lace 0 Mar 5 16:44 /proc/3803/map_files/ $ stat /proc/3803/map_files/400000-4ec000 stat: cannot stat ‘/proc/3803/map_files/400000-4ec000’: Operation not permitted Jan