Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

[John O. <joh...@cl...>]

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:joh...@cl...] 
Sent: 15 April 2015 15:31
To: js...@ac...; 'Florian Krohm'; val...@li...
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:js...@ac...]
Sent: 15 April 2015 15:13
To: Florian Krohm; John OSullivan; val...@li...
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
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users