Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: John OSullivan <john.osullivan@cloudiumsystems.com>
To: buildroot@busybox.net
Subject: [Buildroot] Question about filesystem and Valgrind
Date: Wed, 13 May 2015 10:25:27 +0100	[thread overview]
Message-ID: <00b401d08d5e$c0d63390$42829ab0$@osullivan@cloudiumsystems.com> (raw)
In-Reply-To: <20150512175108.GA8540@postdiluvian.org>

Hi Mark,

Thanks for taking the time to reply, my system boots from nand and then
copies the rootfs into ram, the code is run from ram. As indicated when I
look at /proc/self/maps for libc I see a zero device id. I do not see this
on my Ubuntu machine or on my raspberypi.
Do you think the zero device ID is because my filesystem is in Ram? Has
buildroot configs any control over these Ids? I assume lots of people run
valgrind on embedded systems with similar arrangements and valgrind is
expecting a non zero id for libc.

Regards
John

-----Original Message-----
From: Mark Mason [mailto:mason+buildroot at postdiluvian.org] 
Sent: 12 May 2015 18:51
To: John OSullivan
Cc: buildroot at busybox.net
Subject: Re: [Buildroot] Question about filesystem and Valgrind

John OSullivan <john.osullivan@cloudiumsystems.com> wrote:

> Hi,
> 
> I am not sure if this is a buildroot issue, but buildroot 2015.02 is 
> the tool I use to build my filesystem for an Arm based embedded board that
I am using.
> 
> I am using libc  (rather than uclibc) and when I run Valgrind on my 
> target it fails with.
> 
> > --2993:0:aspacem  Valgrind: FATAL: aspacem assertion failed:
> > --2993:0:aspacem    segment_is_sane
> 
> The issue it is identifying is with the filesystem:
> 
> If I cat /proc/self/maps I get
> 
> 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
> 
> the entry for /lib/libc-2.13.so should not have 00 for the device number.

0 generally means memory.  Are you running from a ramdisk with
execute-in-place?

      reply	other threads:[~2015-05-13  9:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-12 16:38 [Buildroot] Question about filesystem and Valgrind John OSullivan
2015-05-12 17:51 ` Mark Mason
2015-05-13  9:25   ` John OSullivan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='00b401d08d5e$c0d63390$42829ab0$@osullivan@cloudiumsystems.com' \
    --to=john.osullivan@cloudiumsystems.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox