valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] cachegrind parameters for Quark/Galileo

[Josef W. <Jos...@gm...>]

Am 03.11.2014 um 20:55 schrieb Krzysztof Czarnowski:
> Thanks for the comment.
> 
>> To not forget about this, can you enter a bug report?
> 
> Strictly, this is not a bug but "implementation limitation", a feature.
> But since you propose it, I'll send in the report.

"Wish list item" :-)

Josef

> 
> Krzysztof
> 
> 
> On Mon, Nov 3, 2014 at 8:38 PM, Josef Weidendorfer
> <Jos...@gm... <mailto:Jos...@gm...>> wrote:
> 
>     Am 31.10.2014 um 16:46 schrieb Krzysztof Czarnowski:
>     > Cachegrind's cache mode is not very general and I wonder if it makes
>     > sense to use it on Quark to get at least approximate results on an
>     > application's cache performance. The Quark's cache is integrated (both
>     > instruction and data) single level 16kB size with16B line.
>     >
>     > My best bet that is to run
>     > $ valgrind --tool=cachegrind --I1=32,2,16 --D1=32,2,16 --LL=16384,2,16 prog
>     > and look at LL statistics. Sure it's not the real thing but seems the
>     > closest I can get.
> 
>     That should do it, yes. The misses of the LL should be a good
>     estimation for
>     the misses of the L1 unified cache of the Quark, provided that the Quark
>     does
>     something similar to LRU replacement (?).
> 
>     Allowing for more flexible cache hierarchy designs (e.g. just one
>     unified L1)
>     in cachegrind may be possible, but must be done with care. Naive
>     solutions which
>     dynamically check for cache configuration parameters easily could
>     slow down
>     the simulation on every platform significantly...
> 
>     To not forget about this, can you enter a bug report?
> 
>     Josef
> 
>     >
>     > But maybe I miss something and there is some better way... Any
>     > suggestions welcome,
>     > Krzysztof
>     >
>     >
>     >
>     >
>     > ------------------------------------------------------------------------------
>     >
>     >
>     >
>     > _______________________________________________
>     > Valgrind-users mailing list
>     > Val...@li...
>     <mailto:Val...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>     >
> 
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Valgrind-users mailing list
>     Val...@li...
>     <mailto:Val...@li...>
>     https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 

Re: [Valgrind-users] cachegrind parameters for Quark/Galileo

[Krzysztof C. <khc...@gm...>]

Thanks for the comment.

> To not forget about this, can you enter a bug report?

Strictly, this is not a bug but "implementation limitation", a feature. But
since you propose it, I'll send in the report.

Krzysztof


On Mon, Nov 3, 2014 at 8:38 PM, Josef Weidendorfer <
Jos...@gm...> wrote:

> Am 31.10.2014 um 16:46 schrieb Krzysztof Czarnowski:
> > Cachegrind's cache mode is not very general and I wonder if it makes
> > sense to use it on Quark to get at least approximate results on an
> > application's cache performance. The Quark's cache is integrated (both
> > instruction and data) single level 16kB size with16B line.
> >
> > My best bet that is to run
> > $ valgrind --tool=cachegrind --I1=32,2,16 --D1=32,2,16 --LL=16384,2,16
> prog
> > and look at LL statistics. Sure it's not the real thing but seems the
> > closest I can get.
>
> That should do it, yes. The misses of the LL should be a good estimation
> for
> the misses of the L1 unified cache of the Quark, provided that the Quark
> does
> something similar to LRU replacement (?).
>
> Allowing for more flexible cache hierarchy designs (e.g. just one
> unified L1)
> in cachegrind may be possible, but must be done with care. Naive
> solutions which
> dynamically check for cache configuration parameters easily could slow down
> the simulation on every platform significantly...
>
> To not forget about this, can you enter a bug report?
>
> Josef
>
> >
> > But maybe I miss something and there is some better way... Any
> > suggestions welcome,
> > Krzysztof
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] cachegrind parameters for Quark/Galileo

[Josef W. <Jos...@gm...>]

Am 31.10.2014 um 16:46 schrieb Krzysztof Czarnowski:
> Cachegrind's cache mode is not very general and I wonder if it makes
> sense to use it on Quark to get at least approximate results on an
> application's cache performance. The Quark's cache is integrated (both
> instruction and data) single level 16kB size with16B line. 
> 
> My best bet that is to run
> $ valgrind --tool=cachegrind --I1=32,2,16 --D1=32,2,16 --LL=16384,2,16 prog
> and look at LL statistics. Sure it's not the real thing but seems the
> closest I can get.

That should do it, yes. The misses of the LL should be a good estimation for
the misses of the L1 unified cache of the Quark, provided that the Quark
does
something similar to LRU replacement (?).

Allowing for more flexible cache hierarchy designs (e.g. just one
unified L1)
in cachegrind may be possible, but must be done with care. Naive
solutions which
dynamically check for cache configuration parameters easily could slow down
the simulation on every platform significantly...

To not forget about this, can you enter a bug report?

Josef

> 
> But maybe I miss something and there is some better way... Any
> suggestions welcome,
> Krzysztof
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

[Valgrind-users] cachegrind parameters for Quark/Galileo

[Krzysztof C. <khc...@gm...>]

Cachegrind's cache mode is not very general and I wonder if it makes sense
to use it on Quark to get at least approximate results on an application's
cache performance. The Quark's cache is integrated (both instruction and
data) single level 16kB size with16B line.

My best bet that is to run
$ valgrind --tool=cachegrind --I1=32,2,16 --D1=32,2,16 --LL=16384,2,16 prog
and look at LL statistics. Sure it's not the real thing but seems the
closest I can get.

But maybe I miss something and there is some better way... Any suggestions
welcome,
Krzysztof

Re: [Valgrind-users] Valgrind to map all memory access?

[David G. <wi...@ho...>]

I think that's it, exactly.  A lot of information, as expected, but I
can write something to parse it and find what I actually need.
That "memview" also looks useful but probably would have required some
changes. This does exactly what I need.
Thanks a lot, this is going to save me a lot of time.

On Thu, Oct 30, 2014 at 1:44 PM, Eliot Moss <mo...@cs...> wrote:
> You can get a trace of memory accesses from lackey. You would need to
> process it down a bit if all you want is counts and if you want to sort it
> by location, but it would be reasonably easy to do that.
> Eliot Moss
>
> On October 30, 2014 1:36:14 PM EDT, David Goldsmith <wi...@ho...>
> wrote:
>>
>> Hi,
>> is there something in the Valgrind tools that will give me some kind
>> of map of all memory accesses?  I have a chunk of memory and I want to
>> know what parts of it are read from, which are written to, and which
>> are never touched at all.  Cachegrind seems to almost do this, it
>> takes counts of when memory read/write occurs but in addition to the
>> count I also need to know the exact location that it is accessing.
>> Does this functionality exist somewhere in the toolset and I just
>> can't find it?
>> Thanks!
>>
>> ________________________________
>>
>> ________________________________
>>
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Valgrind-users] Valgrind to map all memory access?

[Eliot M. <mo...@cs...>]

You can get a trace of memory accesses from lackey. You would need to process it down a bit if all you want is counts and if you want to sort it by location, but it would be reasonably easy to do that.
Eliot Moss 

On October 30, 2014 1:36:14 PM EDT, David Goldsmith <wi...@ho...> wrote:
>Hi,
>is there something in the Valgrind tools that will give me some kind
>of map of all memory accesses?  I have a chunk of memory and I want to
>know what parts of it are read from, which are written to, and which
>are never touched at all.  Cachegrind seems to almost do this, it
>takes counts of when memory read/write occurs but in addition to the
>count I also need to know the exact location that it is accessing.
>Does this functionality exist somewhere in the toolset and I just
>can't find it?
>Thanks!
>
>------------------------------------------------------------------------------
>_______________________________________________
>Valgrind-users mailing list
>Val...@li...
>https://lists.sourceforge.net/lists/listinfo/valgrind-users

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Valgrind-users] Valgrind to map all memory access?

[Francis G. <fra...@gm...>]

Hi,

I know memview, that displays these accesses in real time.

https://github.com/ajclinto/memview

Francis

2014-10-30 13:41 GMT-04:00 Francis Giraldeau <fra...@gm...>:

> Hi,
>
> I know memview, that displays these accesses in real time.
>
> https://github.com/ajclinto/memview
>
> Francis
>
> 2014-10-30 13:36 GMT-04:00 David Goldsmith <wi...@ho...>:
>
> Hi,
>> is there something in the Valgrind tools that will give me some kind
>> of map of all memory accesses?  I have a chunk of memory and I want to
>> know what parts of it are read from, which are written to, and which
>> are never touched at all.  Cachegrind seems to almost do this, it
>> takes counts of when memory read/write occurs but in addition to the
>> count I also need to know the exact location that it is accessing.
>> Does this functionality exist somewhere in the toolset and I just
>> can't find it?
>> Thanks!
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>
>

[Valgrind-users] Valgrind to map all memory access?

[David G. <wi...@ho...>]

Hi,
is there something in the Valgrind tools that will give me some kind
of map of all memory accesses?  I have a chunk of memory and I want to
know what parts of it are read from, which are written to, and which
are never touched at all.  Cachegrind seems to almost do this, it
takes counts of when memory read/write occurs but in addition to the
count I also need to know the exact location that it is accessing.
Does this functionality exist somewhere in the toolset and I just
can't find it?
Thanks!

Re: [Valgrind-users] Spam (7.009):Re: valgrind-3.10 does not link on

[Florian K. <fl...@ei...>]

On 29.10.2014 12:00, Tom Hughes wrote:
> On 29/10/14 10:29, Julian Seward wrote:
>> On 10/29/2014 09:24 AM, Florian Krohm wrote:
>>> I've fixed this in revision 14673.
>>> Curious, what GCC version have you been using?
>>
>> I think the deciding factor might be, not the gcc version, but the CPU
>> variant being compiled for.  In particular that some AMDs do or don't
>> have
>> special variants of these in hardware, or some such.
> 
> That was my initial assumption, but I'm not sure it can be true because
> a fairly generic build that just targets any old x86_64 or whatever does
> work.

Right.. If GCC knows nothing about, say, __builtin_popcount then
__builtin_popcount(value) appears to the compiler as call to an unknown
(undeclared) function. That compiles OK (K&R allows that) but probably
with a warning. Linking of cause will fail.

   Florian

Re: [Valgrind-users] Spam (7.009):Re: valgrind-3.10 does not link on

[Tom H. <to...@co...>]

On 29/10/14 10:29, Julian Seward wrote:
> On 10/29/2014 09:24 AM, Florian Krohm wrote:
>> I've fixed this in revision 14673.
>> Curious, what GCC version have you been using?
>
> I think the deciding factor might be, not the gcc version, but the CPU
> variant being compiled for.  In particular that some AMDs do or don't have
> special variants of these in hardware, or some such.

That was my initial assumption, but I'm not sure it can be true because 
a fairly generic build that just targets any old x86_64 or whatever does 
work.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Spam (7.009):Re: valgrind-3.10 does not link on

[Julian S. <js...@ac...>]

On 10/29/2014 09:24 AM, Florian Krohm wrote:
> I've fixed this in revision 14673.
> Curious, what GCC version have you been using?

I think the deciding factor might be, not the gcc version, but the CPU
variant being compiled for.  In particular that some AMDs do or don't have
special variants of these in hardware, or some such.

J

Re: [Valgrind-users] valgrind-3.10 does not link on

[Florian K. <fl...@ei...>]

I've fixed this in revision 14673.
Curious, what GCC version have you been using?
I recommend you file a bug report in the future as issues reported on
the mailing list easily get forgotten.

   Florian

On 18.09.2014 10:09, Matthias Apitz wrote:
> 
> Hello,
> 
> This is on a Linux host running:
> 
> valgrind-3.10.0> uname -a
> Linux SRAP03DXOH 2.6.5-7.191-bigsmp #1 SMP Tue Jun 28 14:58:56 UTC 2005 i686 athlon i386 GNU/Linux
> 
> valgrind-3.10.0> CFLAGS="-DPTRACE_GETSIGINFO=0x4202" export CFLAGS
> valgrind-3.10.0> ./configure
> valgrind-3.10.0> gmake
> ...
> 
> mv -f .deps/memcheck_x86_linux-mc_errors.Tpo .deps/memcheck_x86_linux-mc_errors.Po
> ../coregrind/link_tool_exe_linux 0x38000000 gcc  -Wno-long-long -DPTRACE_GETSIGINFO=0x4202   -o memcheck-x86-linux -m32 -mpreferred-stack-boundary=2 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -O2 -static -nodefaultlibs -nostartfiles -u _start  -m32 memcheck_x86_linux-mc_leakcheck.o memcheck_x86_linux-mc_malloc_wrappers.o memcheck_x86_linux-mc_main.o memcheck_x86_linux-mc_translate.o memcheck_x86_linux-mc_machine.o memcheck_x86_linux-mc_errors.o ../coregrind/libcoregrind-x86-linux.a ../VEX/libvex-x86-linux.a -lgcc 
> ../coregrind/libcoregrind-x86-linux.a(libcoregrind_x86_linux_a-syswrap-linux.o)(.text+0x14bba): In function `vgSysWrap_linux_sys_ioctl_after':
> m_syswrap/syswrap-linux.c:8476: undefined reference to `__builtin_popcountll'
> ../coregrind/libcoregrind-x86-linux.a(libcoregrind_x86_linux_a-syswrap-linux.o)(.text+0x1ddcb): In function `vgSysWrap_linux_sys_ioctl_before':
> m_syswrap/syswrap-linux.c:5748: undefined reference to `__builtin_popcountll'
> collect2: ld returned 1 exit status
> gmake[3]: *** [memcheck-x86-linux] Error 1
> gmake[3]: Leaving directory `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0/memcheck'
> gmake[2]: *** [all-recursive] Error 1
> gmake[2]: Leaving directory `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0/memcheck'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0'
> gmake: *** [all] Error 2
> 
> Vy 73
> 
>          matthias
> 

[Valgrind-users] OS X 10.10 support ?

[tornisvk <fre...@gm...>]

Hello,
what should I do to be able to run Valgrind on OS X Yosemite (10.10).
Thanks for reply

Re: [Valgrind-users] Did valgrind ever work in arm64-android?

[Julian S. <js...@ac...>]

> I wonder if anyone ever tried valgrind in arm64-android.

So far, development has been on standard arm64-linux.  It should be
pretty simple to get it working on arm64-android, mostly a question
of fixing the missing instructions that are required.

I don't have a 64-bit Android device to test on, which doesn't help.
Is it possible to have remote access to one?

J

[Valgrind-users] Did valgrind ever work in arm64-android?

[Yingshiuan P. <yin...@li...>]

Hi,

I wonder if anyone ever tried valgrind in arm64-android.

I was trying valgrind to investigate malloc/free related bugs in
android-64. However, even though valgrind was successfully built, android
cannot still lunch an APP with valgrind and had the following errors:

I/ActivityManager( 2262): START u0
{act=android.intent.action.MAIN flg=0x10000000
cmp=com.example.hellojni/.HelloJni}
from pid 3393
I/art ( 3408): Not late-enabling -Xcheck:jni (already on)
I/val.sh ( 3426): ==3427== Memcheck, a memory error detector
I/val.sh ( 3426): ==3427== Copyright (C) 2002-2013, and GNU GPL'd, by
Julian Seward et al.
I/val.sh ( 3426): ==3427== Using Valgrind-3.10.0.SVN and LibVEX; rerun with
-h for copyright info
I/val.sh ( 3426): ==3427== Command: /system/bin/app_process /system/bin
--application --nice-name=com.example.hellojni
com.android.internal.os.WrapperInit 12 3 android.app.ActivityThread
I/val.sh ( 3426): ==3427==
I/val.sh ( 3426): ARM64 front end: load_store
I/val.sh ( 3426): disInstr(arm64): unhandled instruction 0x4CDFA041
I/val.sh ( 3426): disInstr(arm64): 0100'1100 1101'1111 1010'0000 0100'0001
I/val.sh ( 3426): ==3427== valgrind: Unrecognised instruction at address
0x4007b60.
I/val.sh ( 3426): ==3427== at 0x4007B60: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x4004083: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400447B: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x4004C6B: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x4005E0B: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400250F: _start (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400250F: _start (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400250F: _start (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400250F: _start (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400250F: _start (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400250F: _start (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400250F: _start (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== Your program just tried to execute an
instruction that Valgrind
I/val.sh ( 3426): ==3427== did not recognise. There are two possible
reasons for this.
I/val.sh ( 3426): ==3427== 1. Your program has a bug and erroneously jumped
to a non-code
I/val.sh ( 3426): ==3427== location. If you are running Memcheck and you
just saw a
I/val.sh ( 3426): ==3427== warning about a bad jump, it's probably your
program's fault.
I/val.sh ( 3426): ==3427== 2. The instruction is legitimate but Valgrind
doesn't handle it,
I/val.sh ( 3426): ==3427== i.e. it's Valgrind's fault. If you think this is
the case or
I/val.sh ( 3426): ==3427== you are not sure, please let us know and we'll
try to fix it.
I/val.sh ( 3426): ==3427== Either way, Valgrind will now raise a SIGILL
signal which will
I/val.sh ( 3426): ==3427== probably kill your program.
I/val.sh ( 3426): ==3427==
I/val.sh ( 3426): ==3427== Process terminating with default action of
signal 11 (SIGSEGV)
I/val.sh ( 3426): ==3427== Bad permissions for mapped region at address
0x401CFC0
I/val.sh ( 3426): ==3427== at 0x400B854: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x40025FB: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400BAF7: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400BAF7: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400BAF7: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400BAF7: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400BAF7: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400BAF7: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400BAF7: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400BAF7: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400BAF7: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427== by 0x400BAF7: ??? (in /system/bin/linker64)
I/val.sh ( 3426): ==3427==
I/val.sh ( 3426): ==3427== HEAP SUMMARY:
I/val.sh ( 3426): ==3427== in use at exit: 0 bytes in 0 blocks
I/val.sh ( 3426): ==3427== total heap usage: 0 allocs, 0 frees, 0 bytes
allocated
I/val.sh ( 3426): ==3427==
I/val.sh ( 3426): ==3427== All heap blocks were freed – no leaks are
possible
I/val.sh ( 3426): ==3427==
I/val.sh ( 3426): ==3427== For counts of detected and suppressed errors,
rerun with: -v
I/val.sh ( 3426): ==3427== ERROR SUMMARY: 0 errors from 0 contexts
(suppressed: 0 from 0)
I/val.sh ( 3426): val.sh terminated by signal 11
I/Zygote ( 1885): Process 3408 exited cleanly (246)
W/Zygote ( 1885): Error reading pid from wrapped process, child may have
died
W/Zygote ( 1885): java.io.EOFException
W/Zygote ( 1885): at libcore.io.Streams.readFully(Streams.java:83)
W/Zygote ( 1885): at
java.io.DataInputStream.readInt(DataInputStream.java:103)
W/Zygote ( 1885): at
com.android.internal.os.ZygoteConnection.handleParentProc(ZygoteConnection.java:933)
W/Zygote ( 1885): at
com.android.internal.os.ZygoteConnection.runOnce(ZygoteConnection.java:251)
W/Zygote ( 1885): at
com.android.internal.os.ZygoteInit.runSelectLoop(ZygoteInit.java:721)
W/Zygote ( 1885): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:627)
I/ActivityManager( 2262): Start proc com.example.hellojni for activity
com.example.hellojni/.HelloJni: pid=3408 uid=10051 gids=
{50051, 9997, 1028, 1015}
abi=arm64-v8a
D/AndroidRuntime( 3393): Shutting down VM

I saw aosp repo just disabled arm64 build few days ago (
https://android.googlesource.com/platform/external/valgrind/+/3eb9932390b64e5cb416086b329fea2ecfdd49f3
)
and valgrind official site does not claim that it supports arm64-android,
either.

So I'm curious that did anyone ever tried valgrind in arm64-android.

--
潘穎軒 Yingshiuan (Peter) Pan

Re: [Valgrind-users] Valgrind on MIPS Reports Zero Heap Usage

[Woodrow B. <wjb...@nc...>]

Hello,

I've re-built my toolchain to include debugging info (I'm not sure if it
was there before). Hopefully that would guarantee that the libraries aren't
stripped? The end result is, unfortunately, unchanged.

Due to the complexity in implementing Valgrind on our systems, our
priorities have shifted. I'm no longer actively attempting to make the
application function, but will still happily reply with more information if
it is helpful for developers (although it has become apparent that this is
a problem with our own setup, and not with the valgrind product). If you
would still like the results of the detailed detailed tracing, I can send
it to you off-list (it's too long to post here).


 - Woodrow Barlow

On Fri, Oct 10, 2014 at 4:59 PM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Fri, 2014-10-10 at 08:11 -0400, Woodrow Barlow wrote:
> > Hello Sir,
> >
> >
> > Thank you for the help. I'm not entirely sure whether malloc is provided
> by libc.so.0 or by ld-uClibc.so.0,
> > so I've executed the requested command against both. I'm afraid I don't
> know how to interpret the output,
> >  but I've included it below:
> >
> >
> >     $ readelf -d lib/libc.so.0 | grep SONAME
> >
> >      0x0000000e (SONAME)                     Library soname: [libc.so.0]
> >     $ readelf -d lib/ld-uClibc.so.0 | grep SONAME
> >      0x0000000e (SONAME)                     Library soname:
> [ld-uClibc.so.0]
> It is unlikely that ld-uClibc.so.0 does provide malloc.
> So, probably it will be libc.so.0 that will provide it.
>
>
>
> > Finally, as requested, I've run Valgrind with the debugging options
> against a very simple application with malloc
> It looks like the trace below has some lines truncated at column 90 and
> joined with the next line(s).
> E.g. some aspacemgr lines, or (more annoying :), the preload_string value.
> A full not truncated trace would be better.
>
> In any case, the trace shows that LD_PRELOAD is working, as we
> see e.g. the line:
> --1209-- Reading syms from
> /mnt/usb1_1/valgrind/lib/valgrind/vgpreload_memcheck-mips32-linux.so
>
> The difference I see between a working run on a x86/linux and the trace
> below
> is that no 'ACTIVE' redirection is being added.
> On the x86/linux, we obtain some lines such as:
> ...
> --2582--    ------ ACTIVE ------
> ...
> --2582--     0x00286b40 (malloc              ) R-> (1001.0) 0x040078cc
> malloc
>
> which means that the malloc function at 0x00286b40 (which the intercepted
> malloc in libc)
> will be redirected to 0x040078cc, which is the 'intercepting malloc' in
> vgpreload_memcheck.
>
> So, it looks like in your case, the valgrind files to preloaded are
> effectively preloaded,
> that the redirection 'instructions' from these preloaded files are
> properly built,
> giving the 'TOPSPEC' lines
> but that they do not become active when the functions to intercepts are
> seen/found.
>
> Looking at the code that makes such redirections active, this might be
> caused by
> having a stripped library.
> At least, in the x86 working case, I see:
> --2582-- Reading syms from /lib/libc-2.11.2.so
> while no such Reading Syms lines are visible in your trace for the libc.
>
> Valgrind is supposed to detect that the dynamic linker was stripped,
> and report a fatal error, and indicate to install the libc debug info.
> but from what I can see, in the mips case, the warning is only given
> for ld.so.3, while in your case, the loader soname is ld-uClibc.so.0,
> as you do not use the "standard" linux loader.
>
> So, at this state, the best guess is that you have a somewhat stripped
> libraries and/or libraries without debug info, and/or syms for these
> libs are not read properly
> and that makes redirection not working.
>
> There are ways to have more tracing, e.g. by doing
>
> valgrind -v -v -v -d -d -d --debug-dump=syms --trace-symtab-patt=*libc*
> --trace-symtab=yes --trace-redir=yes --trace-malloc=yes
>
> but I think this should be tried only after having verified that libc
> debug info
> is available and/or that symbols are available in your lib.
>
> Philippe
>
>
>
>

Re: [Valgrind-users] Valgrind on MIPS Reports Zero Heap Usage

[Philippe W. <phi...@sk...>]

On Fri, 2014-10-10 at 08:11 -0400, Woodrow Barlow wrote:
> Hello Sir,
> 
> 
> Thank you for the help. I'm not entirely sure whether malloc is provided by libc.so.0 or by ld-uClibc.so.0,
> so I've executed the requested command against both. I'm afraid I don't know how to interpret the output,
>  but I've included it below:
> 
> 
>     $ readelf -d lib/libc.so.0 | grep SONAME
> 
>      0x0000000e (SONAME)                     Library soname: [libc.so.0]
>     $ readelf -d lib/ld-uClibc.so.0 | grep SONAME
>      0x0000000e (SONAME)                     Library soname: [ld-uClibc.so.0]
It is unlikely that ld-uClibc.so.0 does provide malloc.
So, probably it will be libc.so.0 that will provide it.



> Finally, as requested, I've run Valgrind with the debugging options against a very simple application with malloc
It looks like the trace below has some lines truncated at column 90 and
joined with the next line(s).
E.g. some aspacemgr lines, or (more annoying :), the preload_string value.
A full not truncated trace would be better.

In any case, the trace shows that LD_PRELOAD is working, as we
see e.g. the line:
--1209-- Reading syms from /mnt/usb1_1/valgrind/lib/valgrind/vgpreload_memcheck-mips32-linux.so

The difference I see between a working run on a x86/linux and the trace below
is that no 'ACTIVE' redirection is being added.
On the x86/linux, we obtain some lines such as:
...
--2582--    ------ ACTIVE ------
...
--2582--     0x00286b40 (malloc              ) R-> (1001.0) 0x040078cc malloc

which means that the malloc function at 0x00286b40 (which the intercepted malloc in libc)
will be redirected to 0x040078cc, which is the 'intercepting malloc' in vgpreload_memcheck.

So, it looks like in your case, the valgrind files to preloaded are effectively preloaded,
that the redirection 'instructions' from these preloaded files are properly built,
giving the 'TOPSPEC' lines
but that they do not become active when the functions to intercepts are seen/found.

Looking at the code that makes such redirections active, this might be caused by
having a stripped library.
At least, in the x86 working case, I see:
--2582-- Reading syms from /lib/libc-2.11.2.so
while no such Reading Syms lines are visible in your trace for the libc.

Valgrind is supposed to detect that the dynamic linker was stripped,
and report a fatal error, and indicate to install the libc debug info.
but from what I can see, in the mips case, the warning is only given
for ld.so.3, while in your case, the loader soname is ld-uClibc.so.0,
as you do not use the "standard" linux loader.

So, at this state, the best guess is that you have a somewhat stripped
libraries and/or libraries without debug info, and/or syms for these
libs are not read properly
and that makes redirection not working.

There are ways to have more tracing, e.g. by doing

valgrind -v -v -v -d -d -d --debug-dump=syms --trace-symtab-patt=*libc* --trace-symtab=yes --trace-redir=yes --trace-malloc=yes

but I think this should be tried only after having verified that libc debug info
is available and/or that symbols are available in your lib.

Philippe

Re: [Valgrind-users] Valgrind on MIPS Reports Zero Heap Usage

[Woodrow B. <wjb...@nc...>]

Hello Sir,

Thank you for the help. I'm not entirely sure whether malloc is provided by
libc.so.0 or by ld-uClibc.so.0, so I've executed the requested command
against both. I'm afraid I don't know how to interpret the output, but I've
included it below:

    $ readelf -d lib/libc.so.0 | grep SONAME
     0x0000000e (SONAME)                     Library soname: [libc.so.0]
    $ readelf -d lib/ld-uClibc.so.0 | grep SONAME
     0x0000000e (SONAME)                     Library soname:
[ld-uClibc.so.0]

I've also done a readelf against the executable which I am attempting to
test. I am including below a few lines of that output which may be useful.

    Dynamic section
      Tag        Type                         Name/Value
     0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
     0x00000001 (NEEDED)                     Shared library: [libc.so.0]
     0x0000000f (RPATH)                      Library rpath: [//lib]

    Symbol table '.dynsym'
       Num:    Value  Size Type    Bind   Vis      Ndx Name
        27: 00404a40     0 FUNC    GLOBAL DEFAULT  UND free
        97: 00404690     0 FUNC    GLOBAL DEFAULT  UND malloc

Finally, as requested, I've run Valgrind with the debugging options against
a very simple application with malloc (I ran it against the memory leak
test program from the Valgrind FAQ). The output is attached.


 - Woodrow Barlow

On Thu, Oct 9, 2014 at 5:54 PM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Wed, 2014-10-08 at 14:46 -0400, Woodrow Barlow wrote:
> > Basically, Valgrind doesn't detect any heap usage even though I've
> > used the heap. Why might this be? Are any of my assumptions (below)
> > wrong?
> The 3 known causes are:
> A statically linked
> B LD_PRELOAD not supported/not configured
> C linked with a library whose soname does not match the expected name
>
> The tests you have done exclude causes A and B.
> To exclude C, can you check the soname of the library that provides
> malloc ?
> I.e. something like:
>   readelf -d /lib/libc.so.6 | grep SONAME
> giving
>   0x0000000e (SONAME)                     Library soname: [libc.so.6]
>
> The resulting soname should match the default expected soname pattern,
> i.e. on a linux, it is expected to match  libc.so*
> If the soname of your lib does not match the above, then you can use
>     --soname-synonyms=somalloc=xxxxxxxx
> where xxxxxxxx is something which matches your soname
>
> Assuming the above is not the problem, then something else/unknown is
> happening.
>
> Can you then run a small test program dynamically linked, that does
> a malloc call
> and use valgrind options
>    -v -v -v -d -d -d --trace-malloc=yes --trace-redir=yes
> and send the resulting log file?
> If the file is big, you can compress it, and send it only to me.
>
> Hoping this helps
>
> Philippe
>
>
>

Re: [Valgrind-users] Valgrind on MIPS Reports Zero Heap Usage

[Philippe W. <phi...@sk...>]

On Wed, 2014-10-08 at 14:46 -0400, Woodrow Barlow wrote:
> Basically, Valgrind doesn't detect any heap usage even though I've
> used the heap. Why might this be? Are any of my assumptions (below)
> wrong?
The 3 known causes are:
A statically linked
B LD_PRELOAD not supported/not configured
C linked with a library whose soname does not match the expected name

The tests you have done exclude causes A and B.
To exclude C, can you check the soname of the library that provides
malloc ?
I.e. something like:
  readelf -d /lib/libc.so.6 | grep SONAME
giving
  0x0000000e (SONAME)                     Library soname: [libc.so.6]

The resulting soname should match the default expected soname pattern,
i.e. on a linux, it is expected to match  libc.so*
If the soname of your lib does not match the above, then you can use
    --soname-synonyms=somalloc=xxxxxxxx
where xxxxxxxx is something which matches your soname

Assuming the above is not the problem, then something else/unknown is
happening.

Can you then run a small test program dynamically linked, that does 
a malloc call
and use valgrind options
   -v -v -v -d -d -d --trace-malloc=yes --trace-redir=yes
and send the resulting log file?
If the file is big, you can compress it, and send it only to me.

Hoping this helps

Philippe
 

Re: [Valgrind-users] callgrind: jcnd=<followed_count>/<total_count>

[Josef W. <Jos...@gm...>]

Am 26.09.2014 um 04:35 schrieb John Carter:
> I would assume then that
>     followed_count <= total_count
> would always be true.
> 
> This one liner....
> 
> find -name '*.callgrind' | xargs grep jcnd | ruby -nle 'p [$1, $2,$_] if
> ($_ =~ /jcnd=([0-9]+)\/([0-9]+)/) && ($1.to_i > $2.to_i)'
> 
> ...finds thousands of counterexamples,

That should not happen. On which architecture, which Valgrind version?
Can you send me the binary?

Josef

 and if I swap '>'  to '<'.... I
> find thousands of examples again.
> 
> So I have concluded I don't understand what followed_count and
> total_count mean.
> 
> What do they mean?
> 
> -- 
> John Carter
> Phone : (64)(3) 358 6639
> Tait Electronics                        
> PO Box 1645 Christchurch
> New Zealand
> 
> 
> ------------------------------------------------------------------------
> This email, including any attachments, is only for the intended
> recipient. It is subject to copyright, is confidential and may be the
> subject of legal or other privilege, none of which is waived or lost by
> reason of this transmission.
> If you are not an intended recipient, you may not use, disseminate,
> distribute or reproduce such email, any attachments, or any part
> thereof. If you have received a message in error, please notify the
> sender immediately and erase all copies of the message and any attachments.
> Unfortunately, we cannot warrant that the email has not been altered or
> corrupted during transmission nor can we guarantee that any email or any
> attachments are free from computer viruses or other conditions which may
> damage or interfere with recipient data, hardware or software. The
> recipient relies upon its own procedures and assumes all risk of use and
> of opening any attachments.
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

[Valgrind-users] Valgrind on MIPS Reports Zero Heap Usage

[Woodrow B. <wjb...@nc...>]

Greetings,

I'm having some trouble using the Valgrind application on a MIPS embedded
device, and, having exhausted my own troubleshooting capacity, I'm hoping
someone might be able to help me. I'm using valgrind (v3.10.0) to hunt down
a memory leak in a complex application (a heavily modified build of
net-snmp) that is being built as part of a bigger software suite. I am sure
there is a leak (the memory footprint of the application grows linearly
without bound), but valgrind always reports the following upon termination.

    ==1139== HEAP SUMMARY:
    ==1139==     in use at exit: 0 bytes in 0 blocks
    ==1139==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
    ==1139==
    ==1139== All heap blocks were freed -- no leaks are possible

The total heap usage cannot be zero -- there are many, many calls to
`malloc` and `free` throughout the application. Valgrind is still capable
of finding "Invalid Write" errors.

The application in question is being compiled, along with other software
packages, with a uclibc-gcc toolchain for the MIPS processor (uclibc
v0.9.29) to be flashed onto an embedded device running a busybox (v1.17.2)
linux shell. I am running valgrind directly on the device. I use the
following options when launching Valgrind:

    --tool=memcheck --leak-check=full --undef-value-errors=no
--trace-children=yes

Basically, Valgrind doesn't detect any heap usage even though I've used the
heap. Why might this be? Are any of my assumptions (below) wrong?

-----

# What I've Tried

## Simple Test Program

I compiled the simple test program (using the same target and toolchain as
the application above) from the Valgrind [quick-start tutorial](
http://valgrind.org/docs/manual/quick-start.html), to see if Valgrind would
detect the leak. The final output was the same as above: no heap usage.

## Linking Issues?

Valgrind documentation has the following to say on [the FAQ](
http://valgrind.org/docs/manual/faq.html#faq.hiddenbug):

> If your program is statically linked, most Valgrind tools will only work
well if they are able to replace certain functions, such as malloc, with
their own versions. By default, statically linked malloc functions are not
replaced. A key indicator of this is if Memcheck says "All heap blocks were
freed -- no leaks are possible".

The above sounds exactly like my problem, so I checked to see that it's
dynamically linked to the C libraries that contained `malloc` and `free`. I
used the uclibc toolchain's custom `ldd` executable ([I can't use the
native linux `ldd`](http://www.uclibc.org/FAQ.html#ldd)) and the output
included the following lines:

    libc.so.0 => not found (0x00000000)
    /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000)

(The reason they're not found is because I'm running this on the x86 host
device; the mips target device doesn't have an ldd executable.) Based on my
understanding, `malloc` and `free` will be in one of these libraries, and
they seem to be dynamically linked. I also did `readelf` and `nm` on the
executable to confirm that the references to `malloc` and `free` are
undefined (which is characteristic of a dynamically linked executable).

Additionally, I tried launching Valgrind with the
`--soname-synonyms=somalloc=NONE` option as suggested by the FAQ.

## LD_PRELOAD support?

It has been suggested that my toolchain doesn't support LD_PRELOAD. In
order to confirm that it does, I followed [this example](
http://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-using-ld_preload-to-cheat-inject-features-and-investigate-programs/)
to create a simple test library and load it (I replaced `rand()` with a
function that just returns 42). The test worked, so it would seem that my
target supports LD_PRELOAD just fine.

 - Woodrow Barlow

Re: [Valgrind-users] Compiling issue - arm target.

[Philippe W. <phi...@sk...>]

On Tue, 2014-10-07 at 15:23 +0000, Vincent Gilson wrote:
> Hello,
> 
> Valgrind 3.10.0 doesn’t want to compile with my
> ‘arm-926ejs-linux-gnueabi-gcc’ compiler.
> 
>  
> 
> […]
> 
> checking host system type... arm-926ejs-linux-gnueabi
> 
> checking for a supported CPU... no (arm)
> 
> configure: error: Unsupported host architecture. Sorry
> 
> make: *** [package-configure] Error 1
> 
> […]
> 
>  
> 
> Can anyone help me ?
According to what you find in the 'configure' script, only cpus
matching armv7* are expected.
It looks like in your setup, the configure script is guessing 'arm',
and that does not match armv7*

Either you manage to persuade configure to consider your system as an
armv7*, using a valid --host=....... argument.
E.g. something like --host=armv7-unknown-linux

Alternatively you could try to 'patch' configure script
so as to replace the pattern armv7* by e.g. arm* or arm
and hope that the rest will work properly.

Philippe

Re: [Valgrind-users] ulimit under valgrind

[Skarakis, K. <kon...@un...>]

I am not sure I followed your instructions correctly, but I think that did it.

> cat foo
#!/bin/sh
ulimit -n 100000

> ulimit -n
1024

> valgrind --log-file=/tmp/log ./foo
./foo: line 2: ulimit: open files: cannot modify limit: Operation not permitted

> ulimit -n 100010

> ulimit -n
100010

> valgrind --log-file=/tmp/log ./foo

> echo $?
0


Thanks Dan. And thanks Tom.


-----Original Message-----
From: dan...@gm... [mailto:dan...@gm...] On Behalf Of Dan Kegel
Sent: Monday, October 06, 2014 7:08 PM
To: Skarakis, Konstantinos
Cc: Tom Hughes; val...@li...
Subject: Re: [Valgrind-users] ulimit under valgrind

What if you use ulimit on the outside, before valgrind runs, and raise the soft limit to 10 higher than your inner script would?

Re: [Valgrind-users] ulimit under valgrind

[Dan K. <da...@ke...>]

What if you use ulimit on the outside, before valgrind runs, and raise
the soft limit to 10 higher than your inner script would?

Re: [Valgrind-users] ulimit under valgrind

[Skarakis, K. <kon...@un...>]

OK, here is my bad code:

> cat rlimit.c
#include <stdio.h>
#include <sys/time.h>
#include <sys/resource.h>

int main(){
 struct rlimit limit;
 getrlimit(RLIMIT_NOFILE,&limit);
 printf("%d \n",limit.rlim_max);

}



When I just run it I get 8192:
> ./rlimit.o 
8192 


I do get a smaller limit (1024) under Valgrind:
> valgrind ./rlimit.o 
==1070== Memcheck, a memory error detector
==1070== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==1070== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==1070== Command: ./rlimit.o
==1070== 
1024 
==1070== 
==1070== HEAP SUMMARY:
==1070==     in use at exit: 0 bytes in 0 blocks
==1070==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1070== 
==1070== All heap blocks were freed -- no leaks are possible
==1070== 
==1070== For counts of detected and suppressed errors, rerun with: -v
==1070== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)


So I change my script to set to a lower value (100).
> cat foo 
#!/bin/sh
ulimit -n 100


Still doesn't work:

> valgrind ./foo
==1071== Memcheck, a memory error detector
==1071== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==1071== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==1071== Command: ./foo
==1071== 
./foo: line 2: ulimit: open files: cannot modify limit: Operation not permitted


Assuming I am doing something wrong and this small example should work, is there a way to raise the soft/hard limits that valgrind uses?

Also, if the problem was that I was exceeding the hard limit, shouldn't the error be "Limit exceeded" rather than "Operation not permitted".


Costas

-----Original Message-----
From: Tom Hughes [mailto:to...@co...] 
Sent: Monday, October 06, 2014 6:37 PM
To: Skarakis, Konstantinos; val...@li...
Subject: Re: ulimit under valgrind

On 06/10/14 16:22, Tom Hughes wrote:
> On 06/10/14 16:08, Skarakis, Konstantinos wrote:
>
>> I am having trouble running programs that need to use "ulimit" under valgrind. For instance, here is a simple script that changes the limit of open files to 100000. All commands below are executed as root:
>>
>>> cat foo
>> #!/bin/sh
>> ulimit -n 100000
>>
>> I can run it fine on its own.
>>
>>> ./foo
>>> echo $?
>> 0
>>
>> But under valgrind I get blocked with "Operation not permitted":
>
> Because valgrind needs to reserve a few file descriptors for it's own 
> use it effectively reduces the hard limit slightly, so you won't be 
> able to raise your own soft limit above that reduced hard limit.

Actually it's worse than that, we allocate the 10 reserved descriptors immediately above the soft limit (assuming there is space) and effectively convert the initial soft limit to a hard limit.

Tom

--
Tom Hughes (to...@co...)
http://compton.nu/