valgrind-users — General discussion list for Valgrind users

[Valgrind-users] does valgrind support ARM9 based processor

[Ratheendran R <rat...@gm...>]

Hi All,

I am new to this group..

I would like to use valgrind for ARM926 Samsung board, ARM Cortex A9 imx6
freescale board,so kindly let me know valgrind support available on ARM
family.

Thanks in Advance.
RAtheendran

Re: [Valgrind-users] mysterious failures when using valgrind

[Peter v. H. <p.v...@om...>]

Hi John,

>>> The likely cause is __float128 operations being performed as "double precision"
>>> of two __float80 by the Intel math library for x86_64.  Memcheck-3.8.1 implements
>>> __float80 operations as __float64 (ordinary IEEE-754 'double'.)
>
>> Thanks for analyzing this! I assume this means that a fix will be rather
>> complex?
>
> Nearly every user whose programs utilize 80-bit x86 floating point
> is disappointed by memcheck's 64-bit implementation of 80-bit operations.
> This situation is many years old.  The fix requires a major effort
> of design and implementation.

If you don't mind me saying so, this is a pretty incomprehensible design 
decision. This is virtually guaranteed to change the behavior of the 
code, which I would think is a big no-no for a debugging tool. But I 
guess we need to deal with what we have now...

So I see only two options:

- disable the unit tests that fail when running under valgrind.
- switch to gcc's libquadmath. A casual inspection suggests that this is 
based on gmp. It may well be slower than Intel's implementation 
though... I would also need to test if it is mature enough by now.

> If all of your use of 80-bit operations on x86 is indirect as the result
> of __float128, then perhaps you could run on s390, where memcheck has
> good support for the 128-bit hardware floating point.

Unfortunately I do not have access to such a platform. I am very 
surprised that there even is hardware support for 128-bit FP. I always 
thought that that would be too much of a fringe market to be profitable.


Cheers,

Peter.

-- 
Peter van Hoof
Royal Observatory of Belgium
Ringlaan 3
1180 Brussel
Belgium
http://homepage.oma.be/pvh

Re: [Valgrind-users] mysterious failures when using valgrind

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

On 09/26/2013 04:47 PM, John Reiser wrote:
>>> The likely cause is __float128 operations being performed as "double precision"
>>> of two __float80 by the Intel math library for x86_64.  Memcheck-3.8.1 implements
>>> __float80 operations as __float64 (ordinary IEEE-754 'double'.)
> 
>> Thanks for analyzing this! I assume this means that a fix will be rather 
>> complex?
> 
> Nearly every user whose programs utilize 80-bit x86 floating point
> is disappointed by memcheck's 64-bit implementation of 80-bit operations.
> This situation is many years old.  The fix requires a major effort
> of design and implementation.

I'd say it would take about 2-3 weeks for a developer that is familiar
with the VEX IR and the x86_64 front and back ends, to do this.  It
is complex in that it requires changes to the front end, back end, and
to register allocation.  It would also be necessary to check that the
changes don't cause performance regressions for (real) 64-bit FP insns
on x86_64.

So it's not impossible, but given the number and urgency of some of the
other bugs we're faced with, it has so far been difficult to make a case
for allocating developer resources to this.

J

[Valgrind-users] Using valgrind to debug an Android app using the NDK.

[Matthew M. <mat...@th...>]

Hello,

I've successfully install valgrind for android (eventually), and it works when I try it with a command in the adb shell. However, I thought that valgrind could be used to debug NDK android apps. Am I mistaken?

I tried to follow what I read here: http://stackoverflow.com/questions/9123124/how-to-start-an-android-app-with-valgrind

However I could not get it to work. I tried:

setprop wrap.com.matthewmitchell.wakeifyplus "logwrapper /data/local/valgrind" 

But it says "could not set property". I'm not sure what adding "wrap." to the beginning of a package name is supposed to do if anything. Instead I tried:

setprop com.matthewmitchell.wakeifyplus "logwrapper /data/local/valgrind" 

With the shell script:

#!/system/bin/sh

VGPARAMS
='--error-limit=no'
export TMPDIR=/data/data/com.matthewmitchell.
wakeifyplus

exec /data/local/Inst/bin/valgrind $VGPARAMS $*

But when I run:

am start -a android.intent.action.MAIN -n com.matthewmitchell.wakeifyplus/.MainActivity 

nothing shows up in log cat. It doesn't seem as if valgrind is running. So my question is, how do you get valgrind to work with Android apps, if you can at all?

Thanks,

Matthew

Re: [Valgrind-users] mysterious failures when using valgrind

[John R. <jr...@Bi...>]

>> The likely cause is __float128 operations being performed as "double precision"
>> of two __float80 by the Intel math library for x86_64.  Memcheck-3.8.1 implements
>> __float80 operations as __float64 (ordinary IEEE-754 'double'.)

> Thanks for analyzing this! I assume this means that a fix will be rather 
> complex?

Nearly every user whose programs utilize 80-bit x86 floating point
is disappointed by memcheck's 64-bit implementation of 80-bit operations.
This situation is many years old.  The fix requires a major effort
of design and implementation.

If all of your use of 80-bit operations on x86 is indirect as the result
of __float128, then perhaps you could run on s390, where memcheck has
good support for the 128-bit hardware floating point.

-- 

Re: [Valgrind-users] mysterious failures when using valgrind

[Peter v. H. <p.v...@om...>]

Hi John,

>> When run directly, the output is
>>
>> 3fbc79ca10c9242235d511e976394d7a
>>
>> When run through valgrind, the output is:
>
>> 3fbc79ca10c9240e12445f2000000000
>
> This has been entered as bug  https://bugs.kde.org/show_bug.cgi?id=325328 .
> The likely cause is __float128 operations being performed as "double precision"
> of two __float80 by the Intel math library for x86_64.  Memcheck-3.8.1 implements
> __float80 operations as __float64 (ordinary IEEE-754 'double'.)
>

Thanks for analyzing this! I assume this means that a fix will be rather 
complex?


Peter.

-- 
Peter van Hoof
Royal Observatory of Belgium
Ringlaan 3
1180 Brussel
Belgium
http://homepage.oma.be/pvh

Re: [Valgrind-users] mysterious failures when using valgrind

[John R. <jr...@Bi...>]

> When run directly, the output is
> 
> 3fbc79ca10c9242235d511e976394d7a
> 
> When run through valgrind, the output is:

> 3fbc79ca10c9240e12445f2000000000

This has been entered as bug  https://bugs.kde.org/show_bug.cgi?id=325328 .
The likely cause is __float128 operations being performed as "double precision"
of two __float80 by the Intel math library for x86_64.  Memcheck-3.8.1 implements
__float80 operations as __float64 (ordinary IEEE-754 'double'.)

-- 

[Valgrind-users] FW: Helgrind to-do list

[Phil L. <plo...@sa...>]

Travis has commented about the need for #2 for a few suppressions.  I have at least 1 case of #1 in the PDB tree.

From: Phil Longstaff
Sent: Wednesday, September 25, 2013 2:24 PM
To: val...@li...
Subject: Helgrind to-do list

The bottom of the helgrind section of the manual has:

*         For lock order errors, print the complete lock cycle, rather than only doing for size-2 cycles as at present.

*         The conflicting access mechanism sometimes mysteriously fails to show the conflicting access' stack, even when provided with unbounded storage for conflicting access info. This should be investigated.

*         Document races caused by GCC's thread-unsafe code generation for speculative stores. In the interim see http://gcc.gnu.org/ml/gcc/2007-10/msg00266.html and http://lkml.org/lkml/2007/10/24/673.

*         Don't update the lock-order graph, and don't check for errors, when a "try"-style lock operation happens (e.g. pthread_mutex_trylock). Such calls do not add any real restrictions to the locking order, since they can always fail to acquire the lock, resulting in the caller going off and doing Plan B (presumably it will have a Plan B). Doing such checks could generate false lock-order errors and confuse users.

*         Performance can be very poor. Slowdowns on the order of 100:1 are not unusual. There is limited scope for performance improvements.
I'm interested in solutions for a couple of those (#1, #2 and #4).  Is any work being done on them?  If I were to try to tackle them, can someone at least point me in the right place in the code?

Phil

[Valgrind-users] Helgrind to-do list

[Phil L. <plo...@sa...>]

The bottom of the helgrind section of the manual has:

*         For lock order errors, print the complete lock cycle, rather than only doing for size-2 cycles as at present.

*         The conflicting access mechanism sometimes mysteriously fails to show the conflicting access' stack, even when provided with unbounded storage for conflicting access info. This should be investigated.

*         Document races caused by GCC's thread-unsafe code generation for speculative stores. In the interim see http://gcc.gnu.org/ml/gcc/2007-10/msg00266.html and http://lkml.org/lkml/2007/10/24/673.

*         Don't update the lock-order graph, and don't check for errors, when a "try"-style lock operation happens (e.g. pthread_mutex_trylock). Such calls do not add any real restrictions to the locking order, since they can always fail to acquire the lock, resulting in the caller going off and doing Plan B (presumably it will have a Plan B). Doing such checks could generate false lock-order errors and confuse users.

*         Performance can be very poor. Slowdowns on the order of 100:1 are not unusual. There is limited scope for performance improvements.
I'm interested in solutions for a couple of those (#1, #2 and #4).  Is any work being done on them?  If I were to try to tackle them, can someone at least point me in the right place in the code?

Phil

Re: [Valgrind-users] mysterious failures when using valgrind

[Peter v. H. <p.v...@om...>]

On 2013-09-25 06:59, Vasily Golubev wrote:
> It may be helpful to test Valgrind's trunk from svn repository, at first.

I am sure this would be a very quick test for you. For me this would be 
a lot of work as I don't have a trunk version of valgrind handy.

Cheers,

Peter.

> On Tue, Sep 24, 2013 at 7:55 PM, John Reiser <jr...@bi...> wrote:
>>> __float128 exp10(__float128);
>>>
>>> When that routine is called with a negative argument, the return value
>>> changes when I run the code through valgrind, e.g.
>>>
>>> -20 3fbc79ca10c9242235d511e976394d7a (without valgrind)
>>> -20 3fbc79ca10c9240e12445f2000000000 (with valgrind)
>>>
>>> The -20 is the argument for exp10() and was obviously converted to
>>> __float128, and the return value is printed here in hex format.
>>> Initially I thought that the lowest 64 bits were mangled, but from this
>>> example you can see that it is a bit more (the lowest 70 bits differ).
>>
>> This is a bug in memcheck.  Please file a bug report.
>> Construct a short test case program (15 lines or so)
>> which reproduces the output above.  Then go to the main page
>> http://www.valgrind.org/ , click on the Bug Reports link
>> (left column under Contact), describe the problem (much as above),
>> copy+paste the output, and attach the test case program.
>> Please also include the versions of valgrind, compiler, C/math library,
>> and operating system; and kind of hardware.
>> Thank you.
>>
>> --
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>

-- 
Peter van Hoof
Royal Observatory of Belgium
Ringlaan 3
1180 Brussel
Belgium
http://homepage.oma.be/pvh

Re: [Valgrind-users] mysterious failures when using valgrind

[Peter v. H. <p.v...@om...>]

Hi John,

When I tried to create a bug report, it gave me an "invalid username" 
complaint. So I will attach the source file here instead.

Compile with:

g++ valgrindbug.cc -limf -L/path/to/intel/libs

It requires libimf.a, which is part of the Intel C++ or fortran 
compiler. I used the version from Intel 11.1. If you do not have this 
compiler, please contact me offline to discuss this further.

When run directly, the output is

3fbc79ca10c9242235d511e976394d7a

When run through valgrind, the output is:

==31657== Memcheck, a memory error detector
==31657== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==31657== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==31657== Command: a.out
==31657==
3fbc79ca10c9240e12445f2000000000
==31657==
==31657== HEAP SUMMARY:
==31657==     in use at exit: 0 bytes in 0 blocks
==31657==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==31657==
==31657== All heap blocks were freed -- no leaks are possible
==31657==
==31657== For counts of detected and suppressed errors, rerun with: -v
==31657== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

% g++ --version
g++ (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773]

Operating system is openSUSE 12.2, as stated below.


Cheers,

Peter.


On 2013-09-24 17:55, John Reiser wrote:
>> __float128 exp10(__float128);
>>
>> When that routine is called with a negative argument, the return value
>> changes when I run the code through valgrind, e.g.
>>
>> -20 3fbc79ca10c9242235d511e976394d7a (without valgrind)
>> -20 3fbc79ca10c9240e12445f2000000000 (with valgrind)
>>
>> The -20 is the argument for exp10() and was obviously converted to
>> __float128, and the return value is printed here in hex format.
>> Initially I thought that the lowest 64 bits were mangled, but from this
>> example you can see that it is a bit more (the lowest 70 bits differ).
>
> This is a bug in memcheck.  Please file a bug report.
> Construct a short test case program (15 lines or so)
> which reproduces the output above.  Then go to the main page
> http://www.valgrind.org/ , click on the Bug Reports link
> (left column under Contact), describe the problem (much as above),
> copy+paste the output, and attach the test case program.
> Please also include the versions of valgrind, compiler, C/math library,
> and operating system; and kind of hardware.
> Thank you.
>

-- 
Peter van Hoof
Royal Observatory of Belgium
Ringlaan 3
1180 Brussel
Belgium
http://homepage.oma.be/pvh

Re: [Valgrind-users] mysterious failures when using valgrind

[Vasily G. <vas...@gm...>]

It may be helpful to test Valgrind's trunk from svn repository, at first.

On Tue, Sep 24, 2013 at 7:55 PM, John Reiser <jr...@bi...> wrote:
>> __float128 exp10(__float128);
>>
>> When that routine is called with a negative argument, the return value
>> changes when I run the code through valgrind, e.g.
>>
>> -20 3fbc79ca10c9242235d511e976394d7a (without valgrind)
>> -20 3fbc79ca10c9240e12445f2000000000 (with valgrind)
>>
>> The -20 is the argument for exp10() and was obviously converted to
>> __float128, and the return value is printed here in hex format.
>> Initially I thought that the lowest 64 bits were mangled, but from this
>> example you can see that it is a bit more (the lowest 70 bits differ).
>
> This is a bug in memcheck.  Please file a bug report.
> Construct a short test case program (15 lines or so)
> which reproduces the output above.  Then go to the main page
> http://www.valgrind.org/ , click on the Bug Reports link
> (left column under Contact), describe the problem (much as above),
> copy+paste the output, and attach the test case program.
> Please also include the versions of valgrind, compiler, C/math library,
> and operating system; and kind of hardware.
> Thank you.
>
> --
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



-- 
Best Regards,
Vasily

Re: [Valgrind-users] mysterious failures when using valgrind

[John R. <jr...@Bi...>]

> __float128 exp10(__float128);
> 
> When that routine is called with a negative argument, the return value 
> changes when I run the code through valgrind, e.g.
> 
> -20 3fbc79ca10c9242235d511e976394d7a (without valgrind)
> -20 3fbc79ca10c9240e12445f2000000000 (with valgrind)
> 
> The -20 is the argument for exp10() and was obviously converted to 
> __float128, and the return value is printed here in hex format. 
> Initially I thought that the lowest 64 bits were mangled, but from this 
> example you can see that it is a bit more (the lowest 70 bits differ). 

This is a bug in memcheck.  Please file a bug report.
Construct a short test case program (15 lines or so)
which reproduces the output above.  Then go to the main page
http://www.valgrind.org/ , click on the Bug Reports link
(left column under Contact), describe the problem (much as above),
copy+paste the output, and attach the test case program.
Please also include the versions of valgrind, compiler, C/math library,
and operating system; and kind of hardware.
Thank you.

-- 

[Valgrind-users] mysterious failures when using valgrind

[Peter v. H. <p.v...@om...>]

Hi,

I am developing a set of unit tests, which I would also like to run 
through valgrind from time to time. On their own the unit tests run 
absolutely fine, but when I run them through valgrind I get zillions of 
failed tests. I tracked this down to an overloaded routine (called 
exp10) which returns a __float128. The prototype is:

__float128 exp10(__float128);

When that routine is called with a negative argument, the return value 
changes when I run the code through valgrind, e.g.

-20 3fbc79ca10c9242235d511e976394d7a (without valgrind)
-20 3fbc79ca10c9240e12445f2000000000 (with valgrind)

The -20 is the argument for exp10() and was obviously converted to 
__float128, and the return value is printed here in hex format. 
Initially I thought that the lowest 64 bits were mangled, but from this 
example you can see that it is a bit more (the lowest 70 bits differ). 
When exp10 is called with a positive argument, the return value is just 
fine, e.g.

9 401cdcd6500000000000000000000000 (without valgrind)
9 401cdcd6500000000000000000000000 (with valgrind)

This is compiled on an amd64 platform using g++ 4.7.1 and valgrind 3.7.0 
(openSUSE 12.2). I also tried openSUSE 12.3 and got the same behavior 
(this is g++ 4.7.2, valgrind 3.8.1). I am totally mystified by this. 
Especially the part where positive arguments work fine and negative do 
not... Is this a valgrind bug?

Peter.

[Valgrind-users] Valgrind show neither errors nor results

[Léo . <nac...@ho...>]

Hello,
I'm working on a project for my training period.My project works fine but i would track and fix eventual memory leak before using callgring for optimization.I already use valgrind on this project but since i add libiconv, valgrind seem not work anymore.
symptoms:Valgrind end processing but don't display any results on memory usage. But not display error too.
I'v try some ways to run valgrind:valgrind ./Runvalgrind -v ./Runvalgrind -v --leak-check=full ./Runvalgrind -v --leak-check=full --show-reachable=yes ./Runvalgrind -v --leak-check=full --show-reachable=yes --tool=memcheck ./RunBut i have always the folow result :postgre@debian:/media/sf_oxy$ valgrind -v -v -v ./Run==4551== Memcheck, a memory error detector==4551== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.==4551== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info==4551== Command: ./Run==4551== --4551-- Valgrind options:--4551--    --suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp--4551--    -v--4551--    -v--4551--    -v--4551-- Contents of /proc/version:--4551--   Linux version 3.2.0-4-486 (deb...@li...) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 Debian 3.2.46-1+deb7u1--4551-- Arch and hwcaps: X86, x86-sse1-sse2--4551-- Page sizes: currently 4096, max supported 4096--4551-- Valgrind library directory: /usr/lib/valgrind--4551-- TT/TC: VG_(init_tt_tc) (startup of code management)--4551-- TT/TC: cache: 8 sectors of 27597024 bytes each = 220776192 total--4551-- TT/TC: table: 524168 total entries, max occupancy 340704 (65%)--4551-- Reading syms from /lib/i386-linux-gnu/ld-2.13.so (0x4000000)--4551--    svma 0x0000000820, avma 0x0004000820--4551--   Considering /lib/i386-linux-gnu/ld-2.13.so ..--4551--   .. CRC mismatch (computed 734636b7 wanted cf830bae)--4551--   Considering /usr/lib/debug/lib/i386-linux-gnu/ld-2.13.so ..--4551--   .. CRC is valid--4551-- summarise_context(loc_start = 0x60): cannot summarise(why=1):   0x69: [0]={ 48(r3) { u  u  u  c-40 u  u  c-48 c-44 c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- summarise_context(loc_start = 0x69): cannot summarise(why=1):   0x6c: [0]={ 48(r3) { u  u  u  c-40 u  u  u  c-44 c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- summarise_context(loc_start = 0x6c): cannot summarise(why=1):   0x7b: [0]={ 48(r3) { u  u  u  c-40 u  u  u  u  c-4 u  u  u  u  u  u  u  u  u  u  u  }==4551== Adding active redirection:--4551--     new: 0x04016860 (index               ) R-> (0000.0) 0x380552df ???==4551== Adding active redirection:--4551--     new: 0x04016a40 (strlen              ) R-> (0000.0) 0x38055304 ???--4551-- Reading syms from /media/sf_oxy/Run (0x8048000)--4551--    svma 0x000804b390, avma 0x000804b390--4551-- summarise_context(loc_start = 0x4): cannot summarise(why=1):   0xb: [0]={ 0(r1) { u  u  u  u  u  u  u  u  c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- summarise_context(loc_start = 0xb): cannot summarise(why=1):   0xf: [0]={ 0(r1) { u  u  u  u  u  ve{*((dwr5)+(0x0))} u  u  c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- summarise_context(loc_start = 0x9ad): cannot summarise(why=1):   0x9ae: [0]={ 0(r1) { u  u  u  ve{*((dwr5)+(0xfffffffc))} u  ve{*((dwr5)+(0x0))} u  u  c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- summarise_context(loc_start = 0x9ae): cannot summarise(why=1):   0x9af: [0]={ 0(r1) { u  u  u  u  u  ve{*((dwr5)+(0x0))} u  u  c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- summarise_context(loc_start = 0x9af): cannot summarise(why=1):   0x9b2: [0]={ 0(r1) { u  u  u  u  u  u  u  u  c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- Reading syms from /usr/lib/valgrind/memcheck-x86-linux (0x38000000)--4551--    svma 0x0038000000, avma 0x0038000000--4551--   Considering /usr/lib/valgrind/memcheck-x86-linux ..--4551--   .. CRC mismatch (computed f9c53117 wanted 8a91a8b2)--4551--   Considering /usr/lib/debug/usr/lib/valgrind/memcheck-x86-linux ..--4551--   .. CRC is valid--4551--    object doesn't have a dynamic symbol table--4551-- summarise_context(loc_start = 0x5): cannot summarise(why=1):   0xc: [0]={ 0(r7) { u  u  u  u  u  u  u  c-8 c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- summarise_context(loc_start = 0xc): cannot summarise(why=1):   0xf: [0]={ 0(r7) { u  u  u  u  u  ve{*((dwr5)+(0x0))} u  c-8 c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- summarise_context(loc_start = 0x5): cannot summarise(why=1):   0xc: [0]={ 0(r7) { u  u  u  u  u  u  u  c-8 c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- summarise_context(loc_start = 0xc): cannot summarise(why=1):   0xf: [0]={ 0(r7) { u  u  u  u  u  ve{*((dwr5)+(0x0))} u  c-8 c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- summarise_context(loc_start = 0x1c6): cannot summarise(why=1):   0x1c7: [0]={ {*((dwr5)+(0xfffffffc))} { u  u  u  ve{*((dwr5)+(0xfffffff4))} u  ve{*((dwr5)+(0x0))} ve{*((dwr5)+(0xfffffff8))} c-8 c-4 u  u  u  u  u  u  u  u  u  u  u  } [1]={ 0(r7) { u  u  u  u  u  ve{*((dwr5)+(0x0))} u  u  c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- summarise_context(loc_start = 0x1c7): cannot summarise(why=1):   0x1ca: [0]={ {*((dwr5)+(0xfffffffc))} { u  u  u  ve{*((dwr5)+(0xfffffff4))} u  ve{*((dwr5)+(0x0))} ve{*((dwr5)+(0xfffffff8))} c-8 c-4 u  u  u  u  u  u  u  u  u  u  u  } [1]={ 0(r7) { u  u  u  u  u  u  u  u  c-4 u  u  u  u  u  u  u  u  u  u  u  }--4551-- Reading suppressions file: /usr/lib/valgrind/debian-libc6-dbg.supp--4551-- Reading suppressions file: /usr/lib/valgrind/default.supp==4551== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-4551-by-postgre-on-???==4551== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-4551-by-postgre-on-???==4551== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-4551-by-postgre-on-???==4551== ==4551== TO CONTROL THIS PROCESS USING vgdb (which you probably==4551== don't want to do, unless you know exactly what you're doing,==4551== or are doing some strange experiment):==4551==   /usr/lib/valgrind/../../bin/vgdb --pid=4551 ...command...==4551== ==4551== TO DEBUG THIS PROCESS USING GDB: start GDB like this==4551==   /path/to/gdb ./Run==4551== and then give GDB the following command==4551==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=4551==4551== --pid is optional if only one valgrind process is running==4551== --4551-- TT/TC: initialise sector 0--4551-- REDIR: 0x4016a40 (strlen) redirected to 0x38055304 (vgPlain_x86_linux_REDIR_FOR_strlen)--4551-- REDIR: 0x4016860 (index) redirected to 0x380552df (vgPlain_x86_linux_REDIR_FOR_index)--4551-- Reading syms from /usr/lib/valgrind/vgpreload_core-x86-linux.so (0x4021000)--4551--    svma 0x0000000430, avma 0x0004021430--4551--   Considering /usr/lib/valgrind/vgpreload_core-x86-linux.so ..--4551--   .. CRC mismatch (computed bbadfadd wanted 39de28c9)--4551--   Considering /usr/lib/debug/usr/lib/valgrind/vgpreload_core-x86-linux.so ..--4551--   .. CRC is valid--4551-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so (0x4024000)--4551--    svma 0x0000002200, avma 0x0004026200--4551--   Considering /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so ..--4551--   .. CRC mismatch (computed 9b401e29 wanted 9e97adf8)--4551--   Considering /usr/lib/debug/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so ..--4551--   .. CRC is valid==4551== Adding active redirection:--4551--     new: 0x04016eb0 (stpcpy              ) R-> (2020.0) 0x0402aa00 stpcpy--4551-- Reading syms from /usr/lib/libpq.so.5.6 (0x4047000)--4551--    svma 0x0000006310, avma 0x000404d310--4551--   Considering /usr/lib/libpq.so.5.6 ..--4551--   .. CRC mismatch (computed 9900f0af wanted fdb01b3e)--4551--    object doesn't have a symbol table--4551-- Reading syms from /usr/local/lib/libiconv.so.2.5.1 (0x4073000)--4551--    svma 0x00000012c0, avma 0x00040742c0--4551-- Reading syms from /usr/lib/i386-linux-gnu/libstdc++.so.6.0.17 (0x4155000)--4551--    svma 0x000004b040, avma 0x00041a0040--4551--   Considering /usr/lib/i386-linux-gnu/libstdc++.so.6.0.17 ..--4551--   .. CRC mismatch (computed c3328608 wanted 737126b2)--4551--   Considering /usr/lib/debug/usr/lib/i386-linux-gnu/libstdc++.so.6.0.17 ..--4551--   .. CRC is valid==4551== Adding active redirection:--4551--     new: 0x041a24a0 (operator delete(void) R-> (1005.0) 0x04027130 operator delete(void*)==4551== Adding active redirection:--4551--     new: 0x041a24d0 (operator delete(void) R-> (1005.0) 0x04026fd0 operator delete(void*, std::nothrow_t const&)==4551== Adding active redirection:--4551--     new: 0x041a24f0 (operator delete[](vo) R-> (1005.0) 0x04026d10 operator delete[](void*)==4551== Adding active redirection:--4551--     new: 0x041a2510 (operator delete[](vo) R-> (1005.0) 0x04026bb0 operator delete[](void*, std::nothrow_t const&)==4551== Adding active redirection:--4551--     new: 0x041a4790 (operator new(unsigne) R-> (1003.0) 0x04027df0 operator new(unsigned int)==4551== Adding active redirection:--4551--     new: 0x041a4820 (operator new(unsigne) R-> (1001.0) 0x04027c30 operator new(unsigned int, std::nothrow_t const&)==4551== Adding active redirection:--4551--     new: 0x041a48a0 (operator new[](unsig) R-> (1003.0) 0x04027890 operator new[](unsigned int)==4551== Adding active redirection:--4551--     new: 0x041a48e0 (operator new[](unsig) R-> (1001.0) 0x040276d0 operator new[](unsigned int, std::nothrow_t const&)[...] Some CRC pass some other fail--4551--    svma 0x0000000750, avma 0x0004989750--4551--    object doesn't have a symbol table--4551-- REDIR: 0x4316ab0 (strcmp) redirected to 0x40215c0 (_vgnU_ifunc_wrapper)==4551== Adding active redirection:[...]--4551-- REDIR: 0x43b6990 (__memcpy_chk_ssse3) redirected to 0x402b1f0 (__memcpy_chk)NOTICE:  la relation « adres » existe déjà, poursuite du traitement--4551-- REDIR: 0x4317330 (strncpy) redirected to 0x4028c20 (strncpy)Create SQL Structure : 1sRun processingData : 0sProcessus arrêtépostgre@debian:/media/sf_oxy$
(A can past you the full version if need)As you ca see the process end without any error nor results, and i don't know why. Do you have any idea or track to solve this issue
some more information on the project:Build options :g++ \-W -Wall -Wextra -pedantic -ansi -std=c++11 \-o Run \-g -O0 \[MycppFiles] \-pthread \-lpq -I /usr/local/pgsql/lib/ \-liconv -I /usr/local/lib/ \-I /usr/include/postgresql
Libs used :postgre@debian:/media/sf_oxy$ ldd Runlinux-gate.so.1 =>  (0xb7730000)libpq.so.5 => /usr/lib/libpq.so.5 (0xb76ec000)libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0xb760a000)libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb751d000)libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb74f7000)libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb74da000)libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb74c1000)libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb735e000)libssl.so.1.0.0 => /usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0 (0xb7305000)libcrypto.so.1.0.0 => /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 (0xb7146000)libkrb5.so.3 => /usr/lib/i386-linux-gnu/libkrb5.so.3 (0xb7074000)libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xb706f000)libgssapi_krb5.so.2 => /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2 (0xb7031000)libldap_r-2.4.so.2 => /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2 (0xb6fde000)/lib/ld-linux.so.2 (0xb7731000)libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb6fda000)libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb6fc1000)libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3 (0xb6f97000)libkrb5support.so.0 => /usr/lib/i386-linux-gnu/libkrb5support.so.0 (0xb6f8e000)libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 (0xb6f88000)libresolv.so.2 => /lib/i386-linux-gnu/i686/cmov/libresolv.so.2 (0xb6f74000)liblber-2.4.so.2 => /usr/lib/i386-linux-gnu/liblber-2.4.so.2 (0xb6f65000)libsasl2.so.2 => /usr/lib/i386-linux-gnu/libsasl2.so.2 (0xb6f49000)libgnutls.so.26 => /usr/lib/i386-linux-gnu/libgnutls.so.26 (0xb6e80000)libgcrypt.so.11 => /lib/i386-linux-gnu/libgcrypt.so.11 (0xb6dfa000)libtasn1.so.3 => /usr/lib/i386-linux-gnu/libtasn1.so.3 (0xb6de8000)libp11-kit.so.0 => /usr/lib/i386-linux-gnu/libp11-kit.so.0 (0xb6dd6000)libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0xb6dd2000)
Output when i run ./Runpostgre@debian:/media/sf_oxy$ ./RunConstructeur : 1sNOTICE:  la relation « adres » existe déjà, poursuite du traitementCreate SQL Structure : 0sRun processingData : 0swait end processing : 129sTemps d'execution total : 130 Appuyez sur une touche pour continuer...
Thank you in advance for you help.

 		 	   		  

[Valgrind-users] Valgrind on JellyBean - Gives timeout when launching app

[aravindhan a <ara...@gm...>]

Hi ,
    I am trying to run valgrind on JB, i have followed the instruction from,
http://valgrind.org/docs/manual/dist.readme-android.html

I have built the source working fine,I want to detect memory leaks on
Settings application , so  i have got help from this site,
http://blog.mozilla.org/jseward/2011/09/27/valgrind-on-android-current-status/
when i am trying to start the application its not getting launched, time
out happens,
please let me know if you can help me out ?

Please have a look at the logs,

I/dalvikvm( 1112): Exec: /system/bin/sh -c logwrapper logwrapper
/data/local/start_valgrind.sh /system/bin/app_process /system/bin
--application '--nice-name=com.android.settings'
com.android.internal.os.WrapperInit 26 16 'android.app.ActivityThread'
I/start_valgrind.sh( 1124): ******** Starting the Logwrapper *****
I/start_valgrind.sh( 1124): ==1126== Memcheck, a memory error detector
I/start_valgrind.sh( 1124): ==1126== Copyright (C) 2002-2012, and GNU
GPL'd, by Julian Seward et al.
I/start_valgrind.sh( 1124): ==1126== Using Valgrind-3.8.1 and LibVEX; rerun
with -h for copyright info
I/start_valgrind.sh( 1124): ==1126== Command: /system/bin/app_process
/system/bin --application --nice-name=com.android.settings
com.android.internal.os.WrapperInit 26 16 android.app.ActivityThread
I/start_valgrind.sh( 1124): ==1126==
D/skia    ( 1101): SkGraphics::Term() dlclose() BLTsville (CPU)
D/skia    ( 1126): SkGraphics::Init() - BLTsville (CPU) dlopen success
D/AndroidRuntime( 1126):
D/AndroidRuntime( 1126): >>>>>> AndroidRuntime START
com.android.internal.os.RuntimeInit <<<<<<
D/AndroidRuntime( 1126): CheckJNI is OFF
D/dalvikvm( 1126): Trying to load lib libjavacore.so 0x0
I/start_valgrind.sh( 1124): ==1126== Conditional jump or move depends on
uninitialised value(s)
I/start_valgrind.sh( 1124): ==1126==    at 0x4006694: strlen (in
/system/bin/linker)
I/start_valgrind.sh( 1124): ==1126==
I/start_valgrind.sh( 1124): ==1126== Conditional jump or move depends on
uninitialised value(s)
I/start_valgrind.sh( 1124): ==1126==    at 0x4006698: strlen (in
/system/bin/linker)
I/start_valgrind.sh( 1124): ==1126==
D/dalvikvm( 1126): Added shared lib libjavacore.so 0x0
D/dalvikvm( 1126): Trying to load lib libnativehelper.so 0x0
D/dalvikvm( 1126): Added shared lib libnativehelper.so 0x0
D/AndroidRuntime( 1126): Calling main entry
com.android.internal.os.WrapperInit
I/Zygote  (  117): Wrapped process has pid 1126
I/ActivityManager(  298): Start proc com.android.settings for activity
com.android.settings/.Settings: pid=1126 uid=1000 gids={41000, 3003, 1015,
3002, 3001, 1028}
W/ActivityManager(  298): Launch timeout has expired, giving up wake lock!

Thanks and regards,
Aravindhan

Re: [Valgrind-users] Support of instruction vcvt.f64.s32

[Vasily G. <vas...@gm...>]

Mr. Mitnick,

Please, try the latest version of Valgrind (3.9) from svn trunk. It may
help to solve your problem.

Best regards,
Vasily Golubev


On Wed, Sep 18, 2013 at 1:45 AM, Lu Mitnick <kin...@gm...> wrote:

> Hello all,
>
> I use valgrind 3.8.1 with an arm executable. However the valgrind output
> the error message:
>
> ==1276== disInstr(arm): unhandled instruction: 0xEEFA0BEF cond=14(0xE)
> 27:20=239(0xEF) 4:4=0 3:0=15(0xF)
> ==1276== valgrind: Unrecognised instruction at address 0x25afc.
> ==1276==    at 0x25AFC: crude_dragon_weakness (in
> /home/spec_exe/445.gobmk/exe/gobmk_base.armhf-gcc47)
> ==1276== Your program just tried to execute an instruction that Valgrind
> ==1276== did not recognise.  There are two possible reasons for this.
> ==1276== 1. Your program has a bug and erroneously jumped to a non-code
> ==1276==    location.  If you are running Memcheck and you just saw a
> ==1276==    warning about a bad jump, it's probably your program's fault.
> ==1276== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==1276==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==1276==    you are not sure, please let us know and we'll try to fix it.
> ==1276== Either way, Valgrind will now raise a SIGILL signal which will
> ==1276== probably kill your program.
> ==1276==
> ==1276== Process terminating with default action of signal 4 (SIGILL)
> ==1276==  Illegal opcode at address 0x25AFC
> ==1276==    at 0x25AFC: crude_dragon_weakness (in
> /home/spec_exe/445.gobmk/exe/gobmk_base.armhf-gcc47)
>
> I disassemble the executable and find out that the illegal instruction is vcvt.f64.s32
>    d16, d16, #1. I am wondering whether vcvt.f64.s32 is unsupported under
> valgrind or I have misuse valgrind?
>
> Thanks a lot
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>


-- 
Best Regards,
Vasily

[Valgrind-users] Support of instruction vcvt.f64.s32

[Lu M. <kin...@gm...>]

Hello all,

I use valgrind 3.8.1 with an arm executable. However the valgrind output
the error message:

==1276== disInstr(arm): unhandled instruction: 0xEEFA0BEF cond=14(0xE)
27:20=239(0xEF) 4:4=0 3:0=15(0xF)
==1276== valgrind: Unrecognised instruction at address 0x25afc.
==1276==    at 0x25AFC: crude_dragon_weakness (in
/home/spec_exe/445.gobmk/exe/gobmk_base.armhf-gcc47)
==1276== Your program just tried to execute an instruction that Valgrind
==1276== did not recognise.  There are two possible reasons for this.
==1276== 1. Your program has a bug and erroneously jumped to a non-code
==1276==    location.  If you are running Memcheck and you just saw a
==1276==    warning about a bad jump, it's probably your program's fault.
==1276== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1276==    i.e. it's Valgrind's fault.  If you think this is the case or
==1276==    you are not sure, please let us know and we'll try to fix it.
==1276== Either way, Valgrind will now raise a SIGILL signal which will
==1276== probably kill your program.
==1276==
==1276== Process terminating with default action of signal 4 (SIGILL)
==1276==  Illegal opcode at address 0x25AFC
==1276==    at 0x25AFC: crude_dragon_weakness (in
/home/spec_exe/445.gobmk/exe/gobmk_base.armhf-gcc47)

I disassemble the executable and find out that the illegal instruction
is vcvt.f64.s32
   d16, d16, #1. I am wondering whether vcvt.f64.s32 is unsupported under
valgrind or I have misuse valgrind?

Thanks a lot

Re: [Valgrind-users] Valgrind on MIPS64

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

On Thu, 2013-09-12 at 15:20 -0700, min Frank wrote:
> Hi Philippe,
> 
> 
> Thanks for your reply. Do you have idea about the roughly timeline for
> 3.9 release?


I think the idea is to release it in one month or so
(but it was already delayed for some months, due to addition
of new functionalities).

It will be ready sooner if you test the SVN version :).

Philippe

Re: [Valgrind-users] Valgrind on MIPS64

[min F. <min...@gm...>]

Hi Philippe,

*Thanks for your reply. Do you have idea about the roughly timeline for 3.9
release?*
*
*
*Min *


On Thu, Sep 12, 2013 at 12:38 PM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Thu, 2013-09-12 at 10:55 -0700, min Frank wrote:
>
> > Does anyone know if Valgrind works on MIPS64/Linux?  I see
> > MIPS32/Linux is in 3.8.
>
> mips64 support has been added in 3.9.
> (but 3.9 is not released yet, so you must get and compile the SVN
>  version)
>
> Philippe
>
>
>
>

Re: [Valgrind-users] Valgrind on MIPS64

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

On Thu, 2013-09-12 at 10:55 -0700, min Frank wrote:

> Does anyone know if Valgrind works on MIPS64/Linux?  I see
> MIPS32/Linux is in 3.8. 

mips64 support has been added in 3.9.
(but 3.9 is not released yet, so you must get and compile the SVN
 version)

Philippe

Re: [Valgrind-users] valgrind changing application behaviour: triggering boost::math::expm1<e>(e): Overflow Error

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

On Thu, 2013-09-12 at 07:02 +0000, Alexander Mai wrote:
> Hello,
> 
>  
> 
> I’m using valgrind 3.8.0 on a SUSE x86_64 system (SLES 11.1). For a
> simple application performing mathematical calculations the behaviour
> changes when running with valgrind (tool does not matter, lackey is
> sufficient to show). Without valgrind anything is fine and the results
> are as expected, but with valgrind the application produces different
> results for some calculations and finally terminates:

See in user manual 
http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits

the part describing:
"Valgrind has the following limitations in its implementation of
x86/AMD64 floating point relative to IEEE754."

Your problem might be caused by the above.
Then if you can recompile the complete executable, you might be more
lucky by only using 64 bits floats (using SSE only) and
avoid the 80 bits floats.

Philippe

[Valgrind-users] Valgrind on MIPS64

[min F. <min...@gm...>]

Hi,

Does anyone know if Valgrind works on MIPS64/Linux?  I see MIPS32/Linux is
in 3.8.


Thanks

Min

[Valgrind-users] valgrind changing application behaviour: triggering boost::math::expm1<e>(e): Overflow Error

[Alexander M. <ale...@ms...>]

Hello,

I’m using valgrind 3.8.0 on a SUSE x86_64 system (SLES 11.1). For a simple application performing mathematical calculations the behaviour changes when running with valgrind (tool does not matter, lackey is sufficient to show). Without valgrind anything is fine and the results are as expected, but with valgrind the application produces different results for some calculations and finally terminates:

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::overflow_error> >'
  what():  Error in function boost::math::expm1<e>(e): Overflow Error

There are no warnings from valgrind about the binary.

Any ideas what to do?

Kind regards
Alexander Mai

Re: [Valgrind-users] multiplatform support

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

On Wed, 2013-09-11 at 11:59 -0400, Paolo Piselli wrote:
> Perhaps I did not understanding the nature of valgrind multiplatform 
> support, so my previous questions were somewhat unclear.  Allow me to 
> start from a more root question:
> 
> Is a given arch/OS build of valgrind only capable of running guest 
> applications that target that same exact arch/OS?  When fiddling around 
> with --enable-only* configurations it seems that the x86_64 builds don't 
> run i386 applications even if the OS supports running i386 (e.g. 
> x86_64-darwin valgrind libs don't work for i386 apps even though OSX 
> supports i386).  Am I correct to say that "dual-arch" configuration just 
> meaning that both x86_64 and i386 core and tools are built and the 
> launcher picks the correct libs to use, but the individual libs are 
> still limited to instrumenting applications that are of the same 
> architecture that they themselves are compiled for? (i.e. you don't get 
> VM-like capabilities of running another arch/OS by intermediate 
> translation to VEXIR and then JIT into the native arch/OS)
Yes, a dual-arch means in fact to compile twice (most of) valgrind.

In theory, it should be possible to have e.g. a valgrind compiled
for x86_64 "valgrind-ing" a i386 executable, but that is not supported.
Similarly, in theory, e.g. a i386 valgrind could "valgrind" an
arm executable.

But none of this is supported. Feasible but quite some work to do.

Philippe