Menu
▾
▴
valgrind-users
|
From: john <joh...@cl...> - 2015-04-15 08:50:44
|
Hi, I am trying to run valgrind on an embedded arm device without success. The system is built using buildroot-2013.05. The system specifications are given below the following vargrind output: # valgrind -d -d --2993:1:debuglog DebugLog system started by Stage 1, level 2 logging requested --2993:1:launcher no tool requested, defaulting to 'memcheck' --2993:1:launcher no client specified, defaulting platform to 'arm-linux' --2993:1:launcher launching /usr/lib/valgrind/memcheck-arm-linux --2993:1:debuglog DebugLog system started by Stage 2 (main), level 2 logging requested --2993:1:main Welcome to Valgrind version 3.8.1 debug logging --2993:1:main Checking current stack is plausible --2993:1:main Checking initial stack was noted --2993:1:main Starting the address space manager --2993:2:aspacem sp_at_startup = 0x00beeead70 (supplied) --2993:2:aspacem minAddr = 0x0004000000 (computed) --2993:2:aspacem maxAddr = 0x00beee9fff (computed) --2993:2:aspacem cStart = 0x0004000000 (computed) --2993:2:aspacem vStart = 0x0061775000 (computed) --2993:2:aspacem suggested_clstack_top = 0x00bdeeafff (computed) --2993:2:aspacem <<< SHOW_SEGMENTS: Initial layout (5 segments, 0 segnames) --2993:2:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --2993:2:aspacem 1: 0004000000-0061774fff 1495m --2993:2:aspacem 2: RSVN 0061775000-0061775fff 4096 ----- SmFixed --2993:2:aspacem 3: 0061776000-00beee9fff 1495m --2993:2:aspacem 4: RSVN 00beeea000-00ffffffff 1041m ----- SmFixed --2993:2:aspacem >>> --2993:2:aspacem Reading /proc/self/maps --2993:0:aspacem -1: ANON 0038000000-00382a5fff 2777088 r-x-- SmFixed d=0x000 i=8527 o=32768 (0) m=0 /usr/lib/valgrind/memcheck-arm-linux --2993:0:aspacem Valgrind: FATAL: aspacem assertion failed: --2993:0:aspacem segment_is_sane --2993:0:aspacem at m_aspacemgr/aspacemgr-linux.c:1477 (add_segment) --2993:0:aspacem Exiting now. My /proc/self/maps is as follows: -------------------------- 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 b6eea000-b6ef2000 ---p 0013c000 00:00 8937 /lib/libc-2.13.so b6ef2000-b6ef4000 r--p 0013c000 00:00 8937 /lib/libc-2.13.so b6ef4000-b6ef5000 rw-p 0013e000 00:00 8937 /lib/libc-2.13.so b6ef5000-b6ef8000 rw-p 00000000 00:00 0 b6ef8000-b6f66000 r-xp 00000000 00:00 8935 /lib/libm-2.13.so b6f66000-b6f6d000 ---p 0006e000 00:00 8935 /lib/libm-2.13.so b6f6d000-b6f6e000 r--p 0006d000 00:00 8935 /lib/libm-2.13.so b6f6e000-b6f6f000 rw-p 0006e000 00:00 8935 /lib/libm-2.13.so b6f6f000-b6f8f000 r-xp 00000000 00:00 8945 /lib/ld-2.13.so b6f91000-b6f92000 rw-p 00000000 00:00 0 b6f94000-b6f95000 rw-p 00000000 00:00 0 b6f95000-b6f96000 r-xp 00000000 00:00 0 [sigpage] b6f96000-b6f97000 r--p 0001f000 00:00 8945 /lib/ld-2.13.so b6f97000-b6f98000 rw-p 00020000 00:00 8945 /lib/ld-2.13.so bee7c000-bee9d000 rw-p 00000000 00:00 0 [stack] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] ---------------------------------------------- # cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 0 (v7l) Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part : 0xc09 CPU revision : 0 processor : 1 model name : ARMv7 Processor rev 0 (v7l) Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part : 0xc09 CPU revision : 0 Hardware : Xilinx Zynq Platform Revision : 0000 Serial : 0000000000000000 ---------------------------------------------------------- Any suggestions on what the issue might be or where I should start looking regards beckett |
|
From: Julian S. <js...@ac...> - 2015-04-15 09:07:25
|
Could you try that again with the current SVN trunk, please? I don't think anyone has much enthusiasm to chase down obscure failures on an old version (3.8.x). svn co svn://svn.valgrind.org/valgrind/trunk trunk cd trunk ./autogen.sh Then configure/build as normal. J > --2993:2:aspacem Reading /proc/self/maps > --2993:0:aspacem -1: ANON 0038000000-00382a5fff 2777088 r-x-- SmFixed > d=0x000 i=8527 o=32768 (0) m=0 /usr/lib/valgrind/memcheck-arm-linux > --2993:0:aspacem Valgrind: FATAL: aspacem assertion failed: > --2993:0:aspacem segment_is_sane > --2993:0:aspacem at m_aspacemgr/aspacemgr-linux.c:1477 (add_segment) > --2993:0:aspacem Exiting now. |
|
From: John O. <joh...@cl...> - 2015-04-15 12:44:31
|
Hi Julian, Thank you for your reply. I get the same message when I run version 3.10.1. Assertion is at aspacemgr-linux.c:1502 Regards Beckett -----Original Message----- From: Julian Seward [mailto:js...@ac...] Sent: 15 April 2015 10:07 To: joh...@cl...; val...@li... Subject: Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed: Could you try that again with the current SVN trunk, please? I don't think anyone has much enthusiasm to chase down obscure failures on an old version (3.8.x). svn co svn://svn.valgrind.org/valgrind/trunk trunk cd trunk ./autogen.sh Then configure/build as normal. J > --2993:2:aspacem Reading /proc/self/maps > --2993:0:aspacem -1: ANON 0038000000-00382a5fff 2777088 r-x-- SmFixed > d=0x000 i=8527 o=32768 (0) m=0 /usr/lib/valgrind/memcheck-arm-linux > --2993:0:aspacem Valgrind: FATAL: aspacem assertion failed: > --2993:0:aspacem segment_is_sane > --2993:0:aspacem at m_aspacemgr/aspacemgr-linux.c:1477 (add_segment) > --2993:0:aspacem Exiting now. |
|
From: Julian S. <js...@ac...> - 2015-04-15 13:45:44
|
>> --2993:2:aspacem Reading /proc/self/maps >> --2993:0:aspacem -1: ANON 0038000000-00382a5fff 2777088 r-x-- SmFixed >> d=0x000 i=8527 o=32768 (0) m=0 /usr/lib/valgrind/memcheck-arm-linux >> --2993:0:aspacem Valgrind: FATAL: aspacem assertion failed: >> --2993:0:aspacem segment_is_sane >> --2993:0:aspacem at m_aspacemgr/aspacemgr-linux.c:1477 (add_segment) >> --2993:0:aspacem Exiting now. That is a really bizarre failure. I've never seen anything like it before and I can't imagine how it happened. It would be useful to know why sane_NSegment() decided the NSegment wasn't sane. Can you put some debug printing into sane_NSegment ? It's a pretty simple function. The only small detail is, you have to use the following to print stuff: VG_(debugLog)(0, "aspacem", format-string, args ...) J |
|
From: Florian K. <fl...@ei...> - 2015-04-15 14:03:49
|
On 15.04.2015 15:45, Julian Seward wrote: > >>> --2993:2:aspacem Reading /proc/self/maps >>> --2993:0:aspacem -1: ANON 0038000000-00382a5fff 2777088 r-x-- SmFixed >>> d=0x000 i=8527 o=32768 (0) m=0 /usr/lib/valgrind/memcheck-arm-linux 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). Florian |
|
From: John O. <joh...@cl...> - 2015-04-15 14:31:33
|
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
|
|
From: John O. <joh...@cl...> - 2015-08-28 14:25:10
|
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
|
|
From: Tom H. <to...@co...> - 2015-08-28 15:37:52
|
On 28/08/15 15:06, John OSullivan wrote: > 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. Surely the filesystem is still on a device, even if that device is a ramfs device? and that device should have major and minor numbers? Unfortunately unix semantics mean that you always have to have unique device numbers otherwise there is no way to tell if two identical inodes refer to the same file or not. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Florian K. <fl...@ei...> - 2015-08-29 14:44:40
|
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: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 > > |
|
From: John O'S. <joh...@cl...> - 2015-08-31 10:41:03
|
Hi Florian, Thanks for your input, Yes that patch helps, I have moved past the previous assert and can now at least run valgrind to the point where I hit: valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: memcpy valgrind: in an object with soname matching: ld-linux.so.3 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux.so.3 valgrind: valgrind: Possible fixes: (1, short term): install glibc's debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. The package you need valgrind: to install for fix (1) is called valgrind: valgrind: On Debian, Ubuntu: libc6-dbg valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo valgrind: valgrind: Cannot continue -- exiting now. Sorry. I am using buildroot as my build system so I will look at my configuration to see what options I have for this issue. On 29/08/15 15:44, Florian Krohm wrote: > if (filename || (dev != 0 && ino != 0)) |
|
From: Julian S. <js...@ac...> - 2015-04-15 14:13:00
|
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
|
Thanks for helping keep SourceForge clean.
X