Strange segments in /proc/self/maps have been observed in the field.

Namely those with a file name and an inode number but without major
and minor device numbers. See for instance https://bugs.kde.org/124528#c11
This patch also recognises segments with a file name as FileV segments
(which is what valgrind used to do prior to r5818).

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15632

diff --git a/coregrind/m_aspacemgr/aspacemgr-linux.c b/coregrind/m_aspacemgr/aspacemgr-linux.c
index 2cc8f8eb0fa2f031d4088e59d306eaa4b503b5f2..7ce3c996eadbd8f79d8e64cf46e226a9ead5ec47 100644 (file)
--- a/coregrind/m_aspacemgr/aspacemgr-linux.c
+++ b/coregrind/m_aspacemgr/aspacemgr-linux.c
@@ -1519,12 +1519,11 @@ static void read_maps_callback ( Addr addr, SizeT len, UInt prot,
    seg.hasX   = toBool(prot & VKI_PROT_EXEC);
    seg.hasT   = False;
 
-   /* Don't use the presence of a filename to decide if a segment in
-      the initial /proc/self/maps to decide if the segment is an AnonV
-      or FileV segment as some systems don't report the filename. Use
-      the device and inode numbers instead. Fixes bug #124528. */
+   /* A segment in the initial /proc/self/maps is considered a FileV
+      segment if either it has a file name associated with it or both its
+      device and inode numbers are != 0. See bug #124528. */
    seg.kind = SkAnonV;
-   if (dev != 0 && ino != 0) 
+   if (filename || (dev != 0 && ino != 0)) 
       seg.kind = SkFileV;
 
 #  if defined(VGO_darwin)