It used to be that we considered a segment to be a file segment when
/proc/self/maps showed a file name. Then came https://bugs.kde.org/124528
where somebody reported that his maps file had entries with dev and
inode but no file name. Revision 5818 was checked in to fix that. The
new logic now is that a segment is a file segment if dev and inode are
both != 0.
Presence of a file name does not matter. That fixed the problem but
not completely. See https://bugs.kde.org/124528#c11 where the person
reported lines like these:
38000000-38121000 r-xp 00000000 00:00 8503636
/tmp/valgrind/lib/valgrind/x86-linux/memcheck
which is like the stuff you're seeing. Note: dev == 0 and inode != 0 here.
Perhaps we need to change the logic like so:
Index: coregrind/m_aspacemgr/aspacemgr-linux.c
===================================================================
--- coregrind/m_aspacemgr/aspacemgr-linux.c (revision 15595)
+++ coregrind/m_aspacemgr/aspacemgr-linux.c (working copy)
@@ -1510,12 +1510,11 @@
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)
Could you try and see whether that helps?
Florian
On 28.08.2015 16:06, John OSullivan wrote:
> Hi,
>
> I have a problem running valgrind on my embedded system, you can see the
> detail below but essentially the problem is that Valgrind fails with:
> FATAL: aspacem assertion failed
>
> The problem is caused by valgrind detecting a inode number of zero for libc
> b6dae000-b6eea000 r-xp 00000000 00:00 8937 /lib/libc-2.13.so
> ^^^^^
> dev & ino are always zero
>
> My system boots from nand and copies the file system to ram, so the file
> system runs from ram, as far as I can determine when running from ram the
> device and inode number are going to always be zero.
> I tried a similar exercise with the Raspberry PI, if the PIs file system
> reside in Ram (Volatile) then the device and inodes will always be zero, if
> I put the PIs file system on the SD Card (non volatile) then I get non-zero
> device and inodes for the relevant sections.
>
> My question is how am I going to use valgrind on a ram based file system
> when device numbers are going to be zero for libc, is there a configuration
> or setting that I am missing.
>
> Regards
> John O'Sullivan
>
>
>
> device - If the region was mapped from a file, this is the major and minor
> device number (in hex) where the file lives.
> inode - If the region was mapped from a file, this is the file number
>
>
> -----Original Message-----
> From: John OSullivan [mailto:john.osulli...@cloudiumsystems.com]
> Sent: 15 April 2015 15:31
> To: jsew...@acm.org; 'Florian Krohm'; valgrind-users@lists.sourceforge.net
> Subject: Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:
>
> Hi Guys,
> Thanks for the feedback, I will investigate further regarding the file
> system, the system is built using Buildroot, so I will poke around there too
> see if I can get to the bottom of it.
>
> Regards
>
>
> -----Original Message-----
> From: Julian Seward [mailto:jsew...@acm.org]
> Sent: 15 April 2015 15:13
> To: Florian Krohm; John OSullivan; valgrind-users@lists.sourceforge.net
> Subject: Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:
>
> On 15/04/15 16:03, Florian Krohm wrote:
>
>> This isn't sane, because for an ANON segment we should have d=0 and
>> i=0 and o=0.
>> Clearly, this is not an ANON segment but a file segment.
>>
>> I suggest to change the condition on line 3248 in aspacemgr-linux.c
>> (refering to 3.10.1 sources) to if (1) and rerun. That way we can see
>> the contents of /proc/self/maps and can deduce why d == 0 (it should
>> be != 0).
>
> Ah, good point.
>
> So, d is the device number, right? If that's so, then the problem is likely
> because memcheck-arm-linux is on some unusual, hacky, etc, filesystem, and
> the device numbers are zero, when they shouldn't be.
>
> And in fact, you can see that in the /proc/self/maps output that John showed
> in his first message:
>
> 00008000-00106000 r-xp 00000000 00:00 8773 /bin/busybox
> 0010e000-0010f000 rw-p 000fe000 00:00 8773 /bin/busybox
> 0010f000-00111000 rw-p 00000000 00:00 0 [heap]
> b6dae000-b6eea000 r-xp 00000000 00:00 8937 /lib/libc-2.13.so
> ^^^^^
> dev & ino are always zero
>
> So John, what's with the filesystem that you installed Valgrind on?
>
> J
>
>
>
> ----------------------------------------------------------------------------
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your
> own process in accordance with the BPMN 2 standard Learn Process modeling
> best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
