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
