valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Irek S. <isz...@gm...>]

On Thu, Jan 23, 2014 at 11:12 AM, Dallman, John
<joh...@si...> wrote:
>> Do any common platforms, other than x86/x86_64, offer more-than-64-bit "long double"?
>
> Not that they support as full speed hardware operations, AFAIK. SPARC has defined
> registers and instructions for 128-bit floating point, but implements them as
> sequences of operations on 64-bit floats, so they aren't terribly fast.

This is totally wrong.
1. The SPARCV9 specification *requires* support for 128bit floating
point, including load/store and all other operations supported for
single and double floating point operations. It also mandates specific
libc interfaces. Each 128bit SPARCV9 floating point register uses two
64bit floating point registers, so you have half the number of
registers but still can have decent performance

2. Until very recently the SPARCV9 hardware *implementations* did not
support the 128bit floating point instructions in hardware, but since
the SPARCV9 specification mandates their support they are emulated by
kernel traps and separately via the mandated libc wrappers. This
changed with recent Fujitsu CPU versions which implement 128bit
floating point in hardware, including support for register renaming,
with performance almost as fast as the double instructions. Older
Fujitsu SPARCV9 CPU implementations have varying degree of SPARCV9
128bit floating point support, but at least the load/store and add
instructions were always supported.

3. Some SPARC emulators like Transitive implement full SPARCV9 128bit
floating point instruction support, i.e. using the SPARCV9
instructions directly results in faster execution than going through
the libc wrappers and have them executed by Transitive

> IBM System/390 onwards supports 128-bit float in hardware, according to Wikipedia.

Right

Irek

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Christian B. <bor...@de...>]

On 23/01/14 11:12, Dallman, John wrote:
>> Do any common platforms, other than x86/x86_64, offer more-than-64-bit "long double"?
> 
> Not that they support as full speed hardware operations, AFAIK. SPARC has defined
> registers and instructions for 128-bit floating point, but implements them as
> sequences of operations on 64-bit floats, so they aren't terribly fast.
> 
> IBM System/390 onwards supports 128-bit float in hardware, according to Wikipedia.

Yes, s390 does use 128 bit float for long-double (if -mlong-double-128 is used, which is
the default for a while). The valgrind port of s390x supports that, but I think that
the valgrind test coverage for 128 bit float is not that good.


Christian

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Dallman, J. <joh...@si...>]

> Do any common platforms, other than x86/x86_64, offer more-than-64-bit "long double"?

Not that they support as full speed hardware operations, AFAIK. SPARC has defined
registers and instructions for 128-bit floating point, but implements them as
sequences of operations on 64-bit floats, so they aren't terribly fast.

IBM System/390 onwards supports 128-bit float in hardware, according to Wikipedia.

--
John Dallman
-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Patrick J. L. <lop...@gm...>]

On Wed, Jan 22, 2014 at 1:36 PM, Philippe Waroquiers
<phi...@sk...> wrote:
>
> The gcc documentation says for -mfpmath=sse:
>
>   The resulting code should be considerably faster in the majority of
>   cases and avoid the numerical instability problems of 387 code, but
>   may break some existing code that expects temporaries to be 80
>   bits.

"Considerably faster" is, if anything, an understatement. The
performance advantage of "double" vs. "long double" on Intel CPUs is
large, and it grows with each generation of hardware and compilers.
(SSE registers can hold two doubles, AVX can hold four, and compilers
keep getting smarter about vectorization.)

Do any common platforms, other than x86/x86_64, offer more-than-64-bit
"long double"?

A quick search turns up this bug report:

https://bugs.kde.org/show_bug.cgi?id=164298

The commentary there plus the "CLOSED WONTFIX" resolution make it
fairly clear how the Valgrind maintainers feel about this issue.

I would not expect to see "long double" support in Valgrind until
someone outside the core team offers patches and/or money.

 - Pat

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

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

On Wed, 2014-01-22 at 00:19 +0100, Lionel Cons wrote:
> On 22 January 2014 00:03, Tom Hughes <to...@co...> wrote:
> > On 21/01/14 21:49, Tina Harriott wrote:
> >
> >> I am new to this list. Can anyone guide me dissect a problem with
> >> valgrinds long double fp math on x86-64 cpus? We're getting major
> >> malfunctions in our applications because any long double operation
> >> (say y=sinl(x)) contains rubbish in the least significant bits.
> >
> > See the "Limitations" section of the manual:
> >
> >    http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits
> >
> > Specifically the section about floating point limitations.
> 
> "...Whether or not this is critical remains to be seen..."
> 
> Yeah, that comment is so 'funny' that it hurts again. The difference
> between 64bit math and 80bit math is whether a MBDA Meteor missile
> will hit its target or not (Michael Östergren holds a personal grudge
> against valgrind because of weeks lost due this particular
> embarrassing bug screwing up simulations btw), whether the beams in
> LHC will meet the (intended!) target or not, whether math in SAS
> software works or not (warranting a warning in the written
> documentation that running with valgrind to test 3rd party plugins is
> not supported). So the list of things which do *NOT* work with
> valgrind is *impressive* and hurt high value projects, IMHO warranting
> at least the removal of that mocking comment "...Whether or not this
> is critical remains to be seen...". Please.
Effectively, it looks clear that many applications have problems
with this aspect. Would be better to rephrase the doc :).

Now, maybe these applications should better be compilable
with 64 bits floats, and would/should then work properly natively
and under valgrind.

The gcc documentation says for -mfpmath=sse: 

  The resulting code should be considerably faster in the majority of
  cases and avoid the numerical instability problems of 387 code, but
  may break some existing code that expects temporaries to be 80
  bits.

So, you might try to compile your app with the above flag
(I guess you might need a #ifdef or so to have a typedef that
is 80 bits without the above, and 64 bits with the above).

But of course, we all agree it would be nice to have 80 bits floats
properly supported by Valgrind. It is just nobody has time/money/effort
to spend on that :(.

Philippe

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Lionel C. <lio...@gm...>]

On 22 January 2014 00:03, Tom Hughes <to...@co...> wrote:
> On 21/01/14 21:49, Tina Harriott wrote:
>
>> I am new to this list. Can anyone guide me dissect a problem with
>> valgrinds long double fp math on x86-64 cpus? We're getting major
>> malfunctions in our applications because any long double operation
>> (say y=sinl(x)) contains rubbish in the least significant bits.
>
> See the "Limitations" section of the manual:
>
>    http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits
>
> Specifically the section about floating point limitations.

"...Whether or not this is critical remains to be seen..."

Yeah, that comment is so 'funny' that it hurts again. The difference
between 64bit math and 80bit math is whether a MBDA Meteor missile
will hit its target or not (Michael Östergren holds a personal grudge
against valgrind because of weeks lost due this particular
embarrassing bug screwing up simulations btw), whether the beams in
LHC will meet the (intended!) target or not, whether math in SAS
software works or not (warranting a warning in the written
documentation that running with valgrind to test 3rd party plugins is
not supported). So the list of things which do *NOT* work with
valgrind is *impressive* and hurt high value projects, IMHO warranting
at least the removal of that mocking comment "...Whether or not this
is critical remains to be seen...". Please.

Lionel

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

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

On 21/01/14 21:49, Tina Harriott wrote:

> I am new to this list. Can anyone guide me dissect a problem with
> valgrinds long double fp math on x86-64 cpus? We're getting major
> malfunctions in our applications because any long double operation
> (say y=sinl(x)) contains rubbish in the least significant bits.

See the "Limitations" section of the manual:

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

Specifically the section about floating point limitations.

Tom

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

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

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

> Can anyone guide me dissect a problem with
> valgrinds long double fp math on x86-64 cpus? We're getting major
> malfunctions in our applications because any long double operation
> (say y=sinl(x)) contains rubbish in the least significant bits.

This is a well-known and long-standing property of valgrind.  For instance:
http://valgrind.10908.n7.nabble.com/valgrind-does-not-handle-long-double-td41633.html
[Search the 'net for "valgrind long double".]

There is no solution.  If IEEE-754 'double' is not good enough for you,
then valgrind is not good enough for you.

[Valgrind-users] valgrind breaks any long double operation on x86-64

[Tina H. <tin...@gm...>]

I am new to this list. Can anyone guide me dissect a problem with
valgrinds long double fp math on x86-64 cpus? We're getting major
malfunctions in our applications because any long double operation
(say y=sinl(x)) contains rubbish in the least significant bits.

Tina
-- 
Tina Harriott  - Women in Mathematics
Contact: tin...@gm...

Re: [Valgrind-users] [function wrappers] why the finest granularity is "word" not "byte"?

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

On Tue, 2014-01-21 at 06:32 +0000, Jun Yuan wrote:
> Sorry for repeated post if I have post more than once......I did not receive 
> the confirmation for the first time post
> 
> Hello,
> 
> Thanks for the constant help! I have one more question now...
> 
> So far valgrind function wrapper only supports word type for arguments and 
> return types. It is fine when encountering larger than words types like float 
> or double I can always represent double as two words, but how about arguments 
> with finer type like byte(8 bits) or short(16 bit)? If I use word to 
> represent them will it cause any problem such as corrupting the stack upon 
> function returning?

I do not see why byte or short granularity args should cause a problem
as the macros are doing a cast to unsigned long when passing the
arg values to the wrapper function. The wrapper return value is cast
to the type of the result variable.

This should all work ok.

Philippe

[Valgrind-users] [function wrappers] why the finest granularity is "word" not "byte"?

[Jun Y. <YJ...@gm...>]

Sorry for repeated post if I have post more than once......I did not receive 
the confirmation for the first time post

Hello,

Thanks for the constant help! I have one more question now...

So far valgrind function wrapper only supports word type for arguments and 
return types. It is fine when encountering larger than words types like float 
or double I can always represent double as two words, but how about arguments 
with finer type like byte(8 bits) or short(16 bit)? If I use word to 
represent them will it cause any problem such as corrupting the stack upon 
function returning?

Thanks.

[Valgrind-users] [function wrappers] why the finest granularity is "word" not "byte"?

[Jun Y. <YJ...@gm...>]

Hello,

Thanks for the constant help! I have one more question now...

So far valgrind function wrapper only supports word type for arguments and 
return types. It is fine when encountering larger than words types like float 
or double I can always represent double as two words, but how about arguments 
with finer type like byte(8 bits) or short(16 bit)? If I use word to 
represent them will it cause any problem such as corrupting the stack upon 
function returning?

Thanks.

Re: [Valgrind-users] Beginner hg question: mapping address to the variable

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

Am 19.01.2014 15:34, schrieb Philippe Waroquiers:
> On Sat, 2014-01-18 at 10:11 +0100, David Faure wrote:
>> On Friday 17 January 2014 12:36:32 Raghu Reddy wrote:
>>> My question is, how do I find the variable located at the address 0x420A080?
>>> The code was ready compiled with -g option, so I was wondering why it was
>>> unable to point me to the variable.  What can I do to get the actual
>>> variable name or the location where if this is happening?
>>
>> Are you sure that libiomp5.so itself is compiled with -g, not just your 
>> application?

I assume this will get tricky with the OpenMP runtime shipped with the
Intel compiler. Better use GCC to check for races in your code.
And if you know your code is race-free, you make use ICC again.

Josef



>>
>> If yes, maybe try without optimizations (-O0 or nothing instead of -O2), in 
>> case inlining got in the way. But this looks more to me like a missing -g in 
>> the first place.
>>
> I agree with DAvid that it looks like libiomp5 looks compiled without
> -g, so having this lib compiled with debug is the first thing to do.
> 
> Additionally, you might try the option  --read-var-info=yes.
> 
> 
> Philippe
> 
> 
> 
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] Beginner hg question: mapping address to the variable

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

On Sat, 2014-01-18 at 10:11 +0100, David Faure wrote:
> On Friday 17 January 2014 12:36:32 Raghu Reddy wrote:
> > My question is, how do I find the variable located at the address 0x420A080?
> > The code was ready compiled with -g option, so I was wondering why it was
> > unable to point me to the variable.  What can I do to get the actual
> > variable name or the location where if this is happening?
> 
> Are you sure that libiomp5.so itself is compiled with -g, not just your 
> application?
> 
> If yes, maybe try without optimizations (-O0 or nothing instead of -O2), in 
> case inlining got in the way. But this looks more to me like a missing -g in 
> the first place.
> 
I agree with DAvid that it looks like libiomp5 looks compiled without
-g, so having this lib compiled with debug is the first thing to do.

Additionally, you might try the option  --read-var-info=yes.


Philippe

Re: [Valgrind-users] Beginner hg question: mapping address to the variable

[David F. <fa...@kd...>]

On Friday 17 January 2014 12:36:32 Raghu Reddy wrote:
> My question is, how do I find the variable located at the address 0x420A080?
> The code was ready compiled with -g option, so I was wondering why it was
> unable to point me to the variable.  What can I do to get the actual
> variable name or the location where if this is happening?

Are you sure that libiomp5.so itself is compiled with -g, not just your 
application?

If yes, maybe try without optimizations (-O0 or nothing instead of -O2), in 
case inlining got in the way. But this looks more to me like a missing -g in 
the first place.

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

[Valgrind-users] Beginner hg question: mapping address to the variable

[Raghu R. <rag...@no...>]

This is a newbie question, so please bear with me.  J

 

The environment is the following:

Running on an Intel Westmere processor

Red Hat Enterprise Linux Server release 6.4 (Santiago)

Linux fe5 2.6.32-279.32.1.el6.x86_64 #1 SMP Wed Jun 19 05:25:09 EDT 2013
x86_64 x86_64 x86_64 GNU/Linux

Ifort Version 12.0.4

 

Upon running the application I am seeing some messages such as:

 

==20741== ----------------------------------------------------------------

==20741==

==20741== Possible data race during read of size 4 at 0x420A080 by thread #3

==20741== Locks held: none

==20741==    at 0x40B55AD: __kmp_wait_sleep (in
/apps/intel/composerxe-2011.4.191/composerxe-2011.4.191/compiler/lib/intel64
/libiomp5.so)

==20741==    by 0x40B09AF: __kmp_fork_barrier(int, int) (in
/apps/intel/composerxe-2011.4.191/composerxe-2011.4.191/compiler/lib/intel64
/libiomp5.so)

==20741==    by 0x40B0028: __kmp_launch_thread (in
/apps/intel/composerxe-2011.4.191/composerxe-2011.4.191/compiler/lib/intel64
/libiomp5.so)

==20741==    by 0x40D2638: ??? (in
/apps/intel/composerxe-2011.4.191/composerxe-2011.4.191/compiler/lib/intel64
/libiomp5.so)

==20741==    by 0x4C2D0D4: mythread_wrapper (hg_intercepts.c:219)

==20741==    by 0x7E74850: start_thread (in /lib64/libpthread-2.12.so)

==20741==    by 0xF64F6FF: ???

==20741==

==20741== This conflicts with a previous write of size 4 by thread #2

==20741== Locks held: none

==20741==    at 0x40D337B: ??? (in
/apps/intel/composerxe-2011.4.191/composerxe-2011.4.191/compiler/lib/intel64
/libiomp5.so)

==20741==    by 0x4C2D0D4: mythread_wrapper (hg_intercepts.c:219)

==20741==    by 0x7E74850: start_thread (in /lib64/libpthread-2.12.so)

==20741==    by 0x7BE16FF: ???

==20741==

 

My question is, how do I find the variable located at the address 0x420A080?
The code was ready compiled with -g option, so I was wondering why it was
unable to point me to the variable.  What can I do to get the actual
variable name or the location where if this is happening?

 

Thanks,

 

--Raghu

 

 

Re: [Valgrind-users] valgrind with LD_PRELOAD

[Magnus R. <mag...@gm...>]

On 14 January 2014 17:48, Mike Shal <ma...@gm...> wrote:
> On Tue, Jan 14, 2014 at 11:37 AM, Philippe Waroquiers
> <phi...@sk...> wrote:
>> We might maybe need to add a valgrind option
>>    --client-ld-preload=......
>> to avoid such problem ?
> Or maybe a more general --client-environment? That way it's not specific to
> LD_PRELOAD.

How about doing it like sudo etc. do, and have

valgrind LD_PRELOAD=./libfakec.so my_app -e

BR
Magnus Reftel

Re: [Valgrind-users] valgrind with LD_PRELOAD

[Magnus R. <mag...@gm...>]

On 14 January 2014 16:14, Samuel Quiring <Sam...@sy...> wrote:
> Greetings,
>
> I invoke my program as follows:
>
>      LD_PRELOAD=./libfakec.so ./my_app –e
>
> The LD_PRELOAD environment variable tells the loader that libfakec.so should
> be loaded BEFORE every other library including the C runtime, libc.so (see
> http://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick, for
> example).  I am substituting some of my own routines for standard library
> calls.  My app is working like I want, but the question is how to run the
> app under valgrind?

What I did when I was in a similar situation was to have an
initialization function ( marked __attribute__((constructor)) ) which
checked the name of the executable to determine whether to use my
versions of the functions or the libc ones. In my functions, I then
had an if which either did the special things which was the reason for
the LD_PRELOAD, or just delegated to the libc implementation of the
function depending on whether the executable was the target one.

But yes, the suggestions from Philippe Waroquiers and Mike Shal about
passing variables would have made life a lot easier.

BR
Magnus Reftel

Re: [Valgrind-users] valgrind with LD_PRELOAD

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

On Tue, 2014-01-14 at 08:57 -0800, Samuel Quiring wrote:
> | Maybe you can do it with a shell-script wrapper? Eg:
> |
> | run-me.sh:
> 
> | #! /bin/sh
> 
> | LD_PRELOAD=./libfakec.so ./myapp -e
> |
> | Then run:
> |
> | valgrind --trace-children=yes ./run-me.sh
> 
> 
> 
> This has been my approach.  Now I am suspicious that  -
As explained in another mail, it is highly suspected that this
will not help to solve your problem.

>  -trace-children=yes is not working like I hoped.  I get the EXACT
> SAME output whether I have  - -trace–children=yes or do not have that
> option.  So I think there must be more to getting  -
> -trace-children=yes to behave like I want.
> 
> 
> Here is the output.  Every number is the same whether or not I have "-
> -trace-children=yes".
> 
> 
> ==13527== HEAP SUMMARY:
> ==13527==     in use at exit: 19,116 bytes in 584 blocks
> ==13527==   total heap usage: 766 allocs, 182 frees, 29,553 bytes
> allocated
> ==13527== 
> ==13527== LEAK SUMMARY:
> ==13527==    definitely lost: 0 bytes in 0 blocks
> ==13527==    indirectly lost: 0 bytes in 0 blocks
> ==13527==      possibly lost: 0 bytes in 0 blocks
> ==13527==    still reachable: 19,116 bytes in 584 blocks
> ==13527==         suppressed: 0 bytes in 0 blocks
The above must be the output of valgrind for the shell. The shell
behaviour does not change for --trace-children=yes/no.
But when giving --trace-children=yes, you should get additional input
before.
E.g. this is what I get:

==3589== Command: ./run.sh
...
==3590== Command: /home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak
...
==3590== HEAP SUMMARY:
==3590==     in use at exit: 1,000 bytes in 1,000 blocks
==3590==   total heap usage: 1,000 allocs, 0 frees, 1,000 bytes allocated
...
==3589== HEAP SUMMARY:
==3589==     in use at exit: 19,960 bytes in 572 blocks
==3589==   total heap usage: 725 allocs, 153 frees, 26,630 bytes allocated
...

So, with trace children, you see lines for different pids (and a heap summary
result for each process which exits)

Philippe

Re: [Valgrind-users] valgrind with LD_PRELOAD

[Samuel Q. <Sam...@sy...>]

| Maybe you can do it with a shell-script wrapper? Eg:
|
| run-me.sh:
| #! /bin/sh
| LD_PRELOAD=./libfakec.so ./myapp -e
|
| Then run:
|
| valgrind --trace-children=yes ./run-me.sh

This has been my approach.  Now I am suspicious that  - -trace-children=yes is not working like I hoped.  I get the EXACT SAME output whether I have  - -trace–children=yes or do not have that option.  So I think there must be more to getting  - -trace-children=yes to behave like I want.

Here is the output.  Every number is the same whether or not I have "- -trace-children=yes".

==13527== HEAP SUMMARY:
==13527==     in use at exit: 19,116 bytes in 584 blocks
==13527==   total heap usage: 766 allocs, 182 frees, 29,553 bytes allocated
==13527==
==13527== LEAK SUMMARY:
==13527==    definitely lost: 0 bytes in 0 blocks
==13527==    indirectly lost: 0 bytes in 0 blocks
==13527==      possibly lost: 0 bytes in 0 blocks
==13527==    still reachable: 19,116 bytes in 584 blocks
==13527==         suppressed: 0 bytes in 0 blocks



From: Mike Shal <ma...@gm...<mailto:ma...@gm...>>
Date: Tue, Jan 14 9:29 AM
To: Samuel Quiring <sam...@sy...<mailto:sam...@sy...>>
Cc: "val...@li...<mailto:val...@li...>" <val...@li...<mailto:val...@li...>>
Subject: Re: [Valgrind-users] valgrind with LD_PRELOAD

On Tue, Jan 14, 2014 at 10:14 AM, Samuel Quiring <Sam...@sy...<mailto:Sam...@sy...>> wrote:
Greetings,

I invoke my program as follows:

     LD_PRELOAD=./libfakec.so ./my_app –e

The LD_PRELOAD environment variable tells the loader that libfakec.so should be loaded BEFORE every other library including the C runtime, libc.so (see http://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick, for example).  I am substituting some of my own routines for standard library calls.  My app is working like I want, but the question is how to run the app under valgrind?  I tried this:

    valgrind LD_PRELOAD=./libfakec.so ./my_app –e

But valgrind gave and error saying that "LD_PRELOAD=./libfakec.so ./my_app –e" is not a valid path.  In theory, I could put the LD_PRELOAD before the valgrind invocation:

    LD_PRELOAD=./libfakec.so  valgrind  ./my_app –e

But then valgrind would also be using my special library routines and I am pretty sure that will not work.


Maybe you can do it with a shell-script wrapper? Eg:

run-me.sh:
#! /bin/sh
LD_PRELOAD=./libfakec.so ./myapp -e

Then run:

valgrind --trace-children=yes ./run-me.sh

-Mike

Re: [Valgrind-users] valgrind with LD_PRELOAD

[Mike S. <ma...@gm...>]

On Tue, Jan 14, 2014 at 11:37 AM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Tue, 2014-01-14 at 11:29 -0500, Mike Shal wrote:
> > O
> >
> > Maybe you can do it with a shell-script wrapper? Eg:
> >
> >
> > run-me.sh:
> >
> > #! /bin/sh
> >
> > LD_PRELOAD=./libfakec.so ./myapp -e
> >
> >
> > Then run:
> >
> > valgrind --trace-children=yes ./run-me.sh
>
> I do not think so, as the trace-children=yes will cause the valgrind
> launcher to be relaunched to launch myapp. And this valgrind child
> will then use the problematic LD_PRELOAD library.
>
>
Oh, hmm. I had just tried a simple LD_PRELOAD test with wrapping fopen()
and open(). I added a constructor function to the library to see where it
gets initialized, and it does indeed get added to valgrind with
--trace-children=yes. So, scratch that.

We might maybe need to add a valgrind option
>    --client-ld-preload=......
> to avoid such problem ?
>

Or maybe a more general --client-environment? That way it's not specific to
LD_PRELOAD.

-Mike

Re: [Valgrind-users] valgrind with LD_PRELOAD

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

On Tue, 2014-01-14 at 11:29 -0500, Mike Shal wrote:
> O
> 
> Maybe you can do it with a shell-script wrapper? Eg:
> 
> 
> run-me.sh:
> 
> #! /bin/sh
> 
> LD_PRELOAD=./libfakec.so ./myapp -e
> 
> 
> Then run:
> 
> valgrind --trace-children=yes ./run-me.sh

I do not think so, as the trace-children=yes will cause the valgrind
launcher to be relaunched to launch myapp. And this valgrind child
will then use the problematic LD_PRELOAD library.

Philippe

Re: [Valgrind-users] Best valgrind options for finding corrupt memory

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

On Tue, 2014-01-14 at 17:04 +0100, David Faure wrote:
> On Tuesday 14 January 2014 08:03:14 Samuel Quiring wrote:
> > Greetings,
> > 
> > I suspect my program is corrupting (overwriting) memory, e.g., malloc'ing 16
> > bytes for a string that is 17 bytes when you count the nul, then copying 17
> > bytes into the 16 byte area.  What are the best valgrind options for
> > detecting memory corruption?
> 
> The default options :-)
> 
> (memcheck tool)
> 
memcheck default options are effectively ok by default.

But there are some options that you can change if you want to increase
the probability to find a memory corruption or get more info about 
such a bug.

Typically, you might use one or more of the following:

    --redzone-size=<number>   set minimum size of redzones added before/after
                              heap blocks (in bytes). [16]

    --read-var-info=yes|no    read debug info on stack and global variables
                              and use it to print better error messages in
                              tools that make use of it (Memcheck, Helgrind,
                              DRD) [no]
    --freelist-vol=<number>          volume of freed blocks queue     [20000000]
    --freelist-big-blocks=<number>   releases first blocks with size>= [1000000]
    --keep-stacktraces=alloc|free|alloc-and-free|alloc-then-free|none
        stack trace(s) to keep for malloc'd/free'd areas       [alloc-then-free]

The above will impact (increase or decrease) memory and/or cpu used by valgrind.


Philippe

Re: [Valgrind-users] valgrind with LD_PRELOAD

[Mike S. <ma...@gm...>]

On Tue, Jan 14, 2014 at 10:14 AM, Samuel Quiring <
Sam...@sy...> wrote:

> Greetings,
>
> I invoke my program as follows:
>
>      LD_PRELOAD=./libfakec.so ./my_app –e
>
> The LD_PRELOAD environment variable tells the loader that libfakec.so
> should be loaded BEFORE every other library including the C runtime,
> libc.so (see
> http://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick,
> for example).  I am substituting some of my own routines for standard
> library calls.  My app is working like I want, but the question is how to
> run the app under valgrind?  I tried this:
>
>     valgrind LD_PRELOAD=./libfakec.so ./my_app –e
>
> But valgrind gave and error saying that "LD_PRELOAD=./libfakec.so ./my_app
> –e" is not a valid path.  In theory, I could put the LD_PRELOAD before the
> valgrind invocation:
>
>     LD_PRELOAD=./libfakec.so  valgrind  ./my_app –e
>
> But then valgrind would also be using my special library routines and I am
> pretty sure that will not work.
>
>
Maybe you can do it with a shell-script wrapper? Eg:

run-me.sh:
#! /bin/sh
LD_PRELOAD=./libfakec.so ./myapp -e

Then run:

valgrind --trace-children=yes ./run-me.sh

-Mike

Re: [Valgrind-users] valgrind with LD_PRELOAD

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

On Tue, 2014-01-14 at 07:14 -0800, Samuel Quiring wrote:

>     LD_PRELOAD=./libfakec.so  valgrind  ./my_app –e
> 
> 
> But then valgrind would also be using my special library routines and
> I am pretty sure that will not work.
> 
> 
> Is there a way around this?  I am running on CentOS 6.5.


I guess that your second question, related to running a shell script
and its children under Valgrind is related to setting LD_PRELOAD
in the run.sh.
I am not sure that this will solve the possible problem.

Here are some elements:

There are 2 stages for starting your program under valgrind.
The stage 1 is the valgrind launcher (this is the "valgrind"
executable).
This is a normal executable, dynamically linked, and depends
on some "standard shared libs" as shown by
ldd valgrind
	linux-gate.so.1 =>  (0x007ab000)
	libc.so.6 => /lib/libc.so.6 (0x00214000)
	/lib/ld-linux.so.2 (0x001f2000)

valgrind (stage 1) will then launch the stage 2, which is
the specific tool as requested on the command line (e.g. memcheck)
and for the needed platform (e.g. x86).
So, it will e.g. launch memcheck-x86-linux, which is not a dynamic
executable:
ldd memcheck-x86-linux 
	not a dynamic executable

As long as your LD_PRELOAD does not change the behaviour of
the libraries used by valgrind stage 1, then valgrind stage 1
should work properly.
If your LD_PRELOAD replaces things part of e.g. libc, you might
have problems in valgrind stage 1.


If you cannot make all that work, there might be ways to solve that:

* maybe statically link the valgrind stage 1 ?
* otherwise, modify the function setup_client_env in 
    coregrind/m_initimg/initimg-linux.c
  so as to add your specific LD_PRELOAD string only for the client.
  (but I suspect that will however then not work with
    --trace-children=yes, as then the LD_PRELOAD will be used
   by the valgrind stage 1 used to launch the tool on a forked/exec-ed
   children.

Hope this helps, give some feedback about what has worked (or not).

We might maybe need to add a valgrind option
   --client-ld-preload=...... 
to avoid such problem ?
Or alternatively, statically link valgrind (but that means that
valgrind can then only be built if all libs for static linking
are available).



Philippe