valgrind-users

[Valgrind-users] valgrind with LD_PRELOAD

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

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.

Is there a way around this?  I am running on CentOS 6.5.

-Sam

PS: I tried to figure out how to search the archives of this mailing list for LD_PRELOAD, but I could not see a way.

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

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

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?

-Sam

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

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

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)

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

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

[Leif W. <lei...@gm...>]

I like --leak-check=full --track-origins=yes and sometimes --db-attach=yes
if I want to jump in with gdb when the error hits.


On Tue, Jan 14, 2014 at 11:04 AM, David Faure <fa...@kd...> 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)
>
> --
> David Faure, fa...@kd..., http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>
>
>
> ------------------------------------------------------------------------------
> 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
>



-- 
Cheers,
Leif

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

[<Gen...@fr...>]

Hi,

Yes defaults. Starting at 4:52 of this YouTube video you will see this fellow determine that his code also has the strlen problem with malloc:
http://www.youtube.com/watch?v=fvTsFjDuag8


Bye,
Gene Fortanely | Freescale Semiconductor


-----Original Message-----
From: David Faure [mailto:fa...@kd...] 
Sent: Tuesday, January 14, 2014 10:05 AM
To: val...@li...
Cc: Samuel Quiring
Subject: Re: [Valgrind-users] Best valgrind options for finding corrupt memory

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)

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


------------------------------------------------------------------------------
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] 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

[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

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

[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

[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

[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] 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

[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