valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Running Valgrind on ndmp

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

On 12/09/2019 14:00, Eliot Moss wrote:
> On 9/12/2019 5:45 AM, Pallavi Shinde wrote:
> 
>> We ran valgrind on ndmp by inserting the valgrind command within 
>> /etc/init.d/ndmpd, the script that starts ndmpd.
>>
>> valgrind did indeed run on ndmpd and we did get a memory check report, 
>> but it didn't keep itself attached to ndmpd. valgrind dumps the memory 
>> check log and exits. The exit status is '1'. Don't know how to 'keep 
>> valgrind attached' to ndmpd.
>>
>> Would there be any guidance on how to keep valgrind attached to ndmp?
> 
> What do you mean by "keep itself attached"?
> 
>  From what you say, it sounds as if ndmpd ran and finished, so naturally
> valgrind finished.  Everything went as you asked.

As I explained at some length in my previous email what almost
certainly happened is that ndmpd did what most daemons do, and
forked itself into the background with the original process then
exiting.

Now because valgrind follows fork (but not exec) by default it
would normally still follow the other process so I'm guessing
that it actually re-execed, or execed some other program.

Pallavi is the one debugging ndmpd though so I would hope he
knows more abut how it starts up than we do!

So, to repeat myself, either find a way to stop it forking
like that, or find what it is execing and run that directly, or
try --trace-children=yes to make valgrind follow exec.

Tom

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

Re: [Valgrind-users] Running Valgrind on ndmp

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

On 9/12/2019 5:45 AM, Pallavi Shinde wrote:

> We ran valgrind on ndmp by inserting the valgrind command within /etc/init.d/ndmpd, the script that 
> starts ndmpd.
> 
> valgrind did indeed run on ndmpd and we did get a memory check report, but it didn't keep itself 
> attached to ndmpd. valgrind dumps the memory check log and exits. The exit status is '1'. Don't know 
> how to 'keep valgrind attached' to ndmpd.
> 
> Would there be any guidance on how to keep valgrind attached to ndmp?

What do you mean by "keep itself attached"?

 From what you say, it sounds as if ndmpd ran and finished, so naturally
valgrind finished.  Everything went as you asked.

Do you mean that you want all runs of ndmpd to be done under valgrind,
including future ones, not just the one kicked off in the init.d script?

If so, then one way I can think of to do it is:

- rename ndmpd, to, say, ndmpd.bin (for binary)
- write a script called ndmpd that does: valgrind ndmpd.bin $*
- make sure the script is executable, on the path, etc.

Then when ndmpd is launched, you'll launch valgrind on the original ndmpd
program.  This is not so much a "valgrind thing" as a "how to do something on
linux" thing ...

Maybe somebody can think of even nicer ways to do this.

Regards - Eliot Moss

Re: [Valgrind-users] Running Valgrind on ndmp

[Pallavi S. <shi...@gm...>]

Hi,



Thank you for your comments.



We ran valgrind on ndmp by inserting the valgrind command within
/etc/init.d/ndmpd, the script that starts ndmpd.



valgrind did indeed run on ndmpd and we did get a memory check report, but
it didn't keep itself attached to ndmpd. valgrind dumps the memory check
log and exits. The exit status is '1'. Don't know how to 'keep valgrind
attached' to ndmpd.

Would there be any guidance on how to keep valgrind attached to ndmp?

Thanks,
Pallavi

On Mon, Sep 9, 2019, 12:44 PM Tom Hughes <to...@co...> wrote:

> Probably not unless there happens to be somebody here
> that is familiar with "ndmpd" and how it starts up.
>
> You need to make sure that valgrind manages to wind
> up running the actual daemon so if there is some kind
> of launcher process that starts it then you need to
> try and avoid that and start the daemon directly.
>
> Many daemons have some kind of switch to do exactly
> that for debugging purpose, but you are probably more
> familiar with this program and how it starts than
> anybody here.
>
> You can also try --trace-children=yes but that will
> follow across all execs not just the one you are
> interested in.
>
> Tom
>
> On 09/09/2019 07:08, Pallavi Shinde wrote:
> > Hi,
> > Can we get any help here ?
> >
> > Thanks,
> > Pallavi
> >
> > On Thu, Sep 5, 2019, 4:28 PM Pallavi Shinde <shi...@gm...
> > <mailto:shi...@gm...>> wrote:
> >
> >     Hi,
> >
> >     Comments prefixed with [PS] below.
> >
> >      > 1.      service ndmpd stop
> >      > 2.       service ndmpd start
> >      > 3.       valgrind -v --num-callers=50
> >     --log-file=ndmp_valgrind_30_8.log --leak-check=full
> >     /usr/local/ndmp/ndmpd
> >      >
> >      > echo $? Returns 1 after the 3rd command.
> >
> >     Does running ndmpd "by hand" work as the third step?
> >     3. /usr/local/ndmp/ndmpd &   # start in background, note the PID
> >     4. ps -ef   # does ndmpd show with the same PID as given by the
> shell?
> >
> >     [PS] In step 3, the process, if run by hand (/usr/local/ndmp/ndmpd
> >     &) exits immideiately.
> >
> >     If "service ndmpd start" does anything other than execute
> >     /usr/local/ndmp/ndmpd,
> >     then it may be necessary to add a level of indirection through a
> >     shell script
> >     that runs valgrind:
> >
> >     1. service ndmpd stop
> >     2. mv /usr/local/ndmp/ndmpd /usr/local/ndmp/ndmpd.real
> >     3. cat >/usr/local/ndmp/ndmpd <<!EOF!
> >     #!/bin/bash
> >     exec valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log
> >     --leak-check=full /usr/local/ndmp/ndmpd.real
> >     !EOF!
> >     4. chmod +x /usr/local/ndmp/ndmpd
> >     5. service ndmpd start
> >
> >     [PS] service ndmpd start FAILS to run using a wrapper.
> >
> >     $ service ndmpd stop
> >     Stopping ndmpd:                                            [  OK  ]
> >
> >     $ service ndmpd start
> >     Starting ndmpd:                                            [FAILED]
> >
> >     $ cat /usr/local/ndmp/ndmpd
> >     #!/bin/bash
> >     #/usr/local/ndmp/ndmpd.real
> >     exec valgrind -v --num-callers=50 --log-file=ndmp_valgrind_04_09.log
> >     --leak-check=full /usr/local/ndmp/ndmpd.real
> >
> >     $ ps -ef | grep valgrind
> >     root     22481     1  0 11:38 ?        00:00:00 valgrind -v
> >     --num-callers=50 --log-file=ndmp_valgrind_04_09.log
> >     --leak-check=full /usr/local/ndmp/ndmpd.real
> >     root     23269  4513  0 11:42 pts/4    00:00:00 grep --color=auto
> >     valgrind
> >
> >     $ ps -ef | grep ndmpd
> >     root     22481     1  0 11:38 ?        00:00:00 valgrind -v
> >     --num-callers=50 --log-file=ndmp_valgrind_04_09.log
> >     --leak-check=full /usr/local/ndmp/ndmpd.real
> >     root     23309  4513  0 11:42 pts/4    00:00:00 grep --color=auto
> ndmpd
> >
> >     As  per our observation ndmp internally starts session monitor. But
> >     in this case we were not able to see the session monitor and ndmp.
> >
> >     Is there any other way to run valgrind on ndmp ?
> >
> >     Thanks,
> >     Pallavi
> >
> >     On Fri, Aug 30, 2019, 8:19 PM John Reiser <jr...@bi...
> >     <mailto:jr...@bi...>> wrote:
> >
> >          > 1.      service ndmpd stop
> >          > 2.       service ndmpd start
> >          > 3.       valgrind -v --num-callers=50
> >         --log-file=ndmp_valgrind_30_8.log --leak-check=full
> >         /usr/local/ndmp/ndmpd
> >          >
> >          > echo $? Returns 1 after the 3rd command.
> >
> >         Does running ndmpd "by hand" work as the third step?
> >         3. /usr/local/ndmp/ndmpd &   # start in background, note the PID
> >         4. ps -ef   # does ndmpd show with the same PID as given by the
> >         shell?
> >
> >         If "service ndmpd start" does anything other than execute
> >         /usr/local/ndmp/ndmpd,
> >         then it may be necessary to add a level of indirection through a
> >         shell script
> >         that runs valgrind:
> >
> >         1. service ndmpd stop
> >         2. mv /usr/local/ndmp/ndmpd /usr/local/ndmp/ndmpd.real
> >         3. cat >/usr/local/ndmp/ndmpd <<!EOF!
> >         #!/bin/bash
> >         exec valgrind -v --num-callers=50
> >         --log-file=ndmp_valgrind_30_8.log --leak-check=full
> >         /usr/local/ndmp/ndmpd.real
> >         !EOF!
> >         4. chmod +x /usr/local/ndmp/ndmpd
> >         5. service ndmpd start
> >
> >         --
> >
> >
> >
> >         _______________________________________________
> >         Valgrind-users mailing list
> >         Val...@li...
> >         <mailto:Val...@li...>
> >         https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
> >
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
>
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>

Re: [Valgrind-users] No Git tag for v3.15.0

[Mark W. <ma...@kl...>]

Hi Mike,

On Mon, 2019-09-09 at 14:09 +0100, Mike Crowe wrote:
> The Valgrind Git repository at 
> https://sourceware.org/git/?p=valgrind.git
> has a VALGRIND_3_14_0 tag, but no tag corresponding to the 3.15.0
> release.
> It looks like the tag should reference
> 608cb11914e5f23d0fc12c61dad29c5c7952a1de. Is that correct?

Yeah, it is slightly ambiguous, since we have a chicken and egg problem
:) The NEWS file has a git commit hash describing the commit that is
the particular version. But then of course that is committed first
before making the release, creating... a new hash.

But I think you are correct that the official release tar ball was
created from this (second) hash
608cb11914e5f23d0fc12c61dad29c5c7952a1de.

Julian would you mind creating a signed tag for this commit?
Using the same pgp key you used to sign the release tar ball?

git tag -s -m "valgrind 3.15.0 release" VALGRIND_3_15_0 \
    608cb11914e5f23d0fc12c61dad29c5c7952a1de
git push --tags

We could also allow lightweight tags on the sourceware repo, but it
seems better if the release master creates a full signed tag to make
sure the tag and release tar ball are created from the same source.

Cheers,

Mark

[Valgrind-users] No Git tag for v3.15.0

[Mike C. <ma...@mc...>]

The Valgrind Git repository at https://sourceware.org/git/?p=valgrind.git
has a VALGRIND_3_14_0 tag, but no tag corresponding to the 3.15.0 release.
It looks like the tag should reference
608cb11914e5f23d0fc12c61dad29c5c7952a1de. Is that correct?

Thanks.

Mike.

Re: [Valgrind-users] Running Valgrind on ndmp

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

Probably not unless there happens to be somebody here
that is familiar with "ndmpd" and how it starts up.

You need to make sure that valgrind manages to wind
up running the actual daemon so if there is some kind
of launcher process that starts it then you need to
try and avoid that and start the daemon directly.

Many daemons have some kind of switch to do exactly
that for debugging purpose, but you are probably more
familiar with this program and how it starts than
anybody here.

You can also try --trace-children=yes but that will
follow across all execs not just the one you are
interested in.

Tom

On 09/09/2019 07:08, Pallavi Shinde wrote:
> Hi,
> Can we get any help here ?
> 
> Thanks,
> Pallavi
> 
> On Thu, Sep 5, 2019, 4:28 PM Pallavi Shinde <shi...@gm... 
> <mailto:shi...@gm...>> wrote:
> 
>     Hi,
> 
>     Comments prefixed with [PS] below.
> 
>      > 1.      service ndmpd stop
>      > 2.       service ndmpd start
>      > 3.       valgrind -v --num-callers=50
>     --log-file=ndmp_valgrind_30_8.log --leak-check=full
>     /usr/local/ndmp/ndmpd
>      >
>      > echo $? Returns 1 after the 3rd command.
> 
>     Does running ndmpd "by hand" work as the third step?
>     3. /usr/local/ndmp/ndmpd &   # start in background, note the PID
>     4. ps -ef   # does ndmpd show with the same PID as given by the shell?
> 
>     [PS] In step 3, the process, if run by hand (/usr/local/ndmp/ndmpd
>     &) exits immideiately.
> 
>     If "service ndmpd start" does anything other than execute
>     /usr/local/ndmp/ndmpd,
>     then it may be necessary to add a level of indirection through a
>     shell script
>     that runs valgrind:
> 
>     1. service ndmpd stop
>     2. mv /usr/local/ndmp/ndmpd /usr/local/ndmp/ndmpd.real
>     3. cat >/usr/local/ndmp/ndmpd <<!EOF!
>     #!/bin/bash
>     exec valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log
>     --leak-check=full /usr/local/ndmp/ndmpd.real
>     !EOF!
>     4. chmod +x /usr/local/ndmp/ndmpd
>     5. service ndmpd start
> 
>     [PS] service ndmpd start FAILS to run using a wrapper.
> 
>     $ service ndmpd stop
>     Stopping ndmpd:                                            [  OK  ]
> 
>     $ service ndmpd start
>     Starting ndmpd:                                            [FAILED]
> 
>     $ cat /usr/local/ndmp/ndmpd
>     #!/bin/bash
>     #/usr/local/ndmp/ndmpd.real
>     exec valgrind -v --num-callers=50 --log-file=ndmp_valgrind_04_09.log
>     --leak-check=full /usr/local/ndmp/ndmpd.real
> 
>     $ ps -ef | grep valgrind
>     root     22481     1  0 11:38 ?        00:00:00 valgrind -v
>     --num-callers=50 --log-file=ndmp_valgrind_04_09.log
>     --leak-check=full /usr/local/ndmp/ndmpd.real
>     root     23269  4513  0 11:42 pts/4    00:00:00 grep --color=auto
>     valgrind
> 
>     $ ps -ef | grep ndmpd
>     root     22481     1  0 11:38 ?        00:00:00 valgrind -v
>     --num-callers=50 --log-file=ndmp_valgrind_04_09.log
>     --leak-check=full /usr/local/ndmp/ndmpd.real
>     root     23309  4513  0 11:42 pts/4    00:00:00 grep --color=auto ndmpd
> 
>     As  per our observation ndmp internally starts session monitor. But
>     in this case we were not able to see the session monitor and ndmp.
> 
>     Is there any other way to run valgrind on ndmp ?
> 
>     Thanks,
>     Pallavi
> 
>     On Fri, Aug 30, 2019, 8:19 PM John Reiser <jr...@bi...
>     <mailto:jr...@bi...>> wrote:
> 
>          > 1.      service ndmpd stop
>          > 2.       service ndmpd start
>          > 3.       valgrind -v --num-callers=50
>         --log-file=ndmp_valgrind_30_8.log --leak-check=full
>         /usr/local/ndmp/ndmpd
>          >
>          > echo $? Returns 1 after the 3rd command.
> 
>         Does running ndmpd "by hand" work as the third step?
>         3. /usr/local/ndmp/ndmpd &   # start in background, note the PID
>         4. ps -ef   # does ndmpd show with the same PID as given by the
>         shell?
> 
>         If "service ndmpd start" does anything other than execute
>         /usr/local/ndmp/ndmpd,
>         then it may be necessary to add a level of indirection through a
>         shell script
>         that runs valgrind:
> 
>         1. service ndmpd stop
>         2. mv /usr/local/ndmp/ndmpd /usr/local/ndmp/ndmpd.real
>         3. cat >/usr/local/ndmp/ndmpd <<!EOF!
>         #!/bin/bash
>         exec valgrind -v --num-callers=50
>         --log-file=ndmp_valgrind_30_8.log --leak-check=full
>         /usr/local/ndmp/ndmpd.real
>         !EOF!
>         4. chmod +x /usr/local/ndmp/ndmpd
>         5. service ndmpd start
> 
>         -- 
> 
> 
> 
>         _______________________________________________
>         Valgrind-users mailing list
>         Val...@li...
>         <mailto:Val...@li...>
>         https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 


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

Re: [Valgrind-users] Running Valgrind on ndmp

[Pallavi S. <shi...@gm...>]

Hi,
Can we get any help here ?

Thanks,
Pallavi

On Thu, Sep 5, 2019, 4:28 PM Pallavi Shinde <shi...@gm...> wrote:

> Hi,
>
> Comments prefixed with [PS] below.
>
> > 1.      service ndmpd stop
> > 2.       service ndmpd start
> > 3.       valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log
> --leak-check=full /usr/local/ndmp/ndmpd
> >
> > echo $? Returns 1 after the 3rd command.
>
> Does running ndmpd "by hand" work as the third step?
> 3. /usr/local/ndmp/ndmpd &   # start in background, note the PID
> 4. ps -ef   # does ndmpd show with the same PID as given by the shell?
>
> [PS] In step 3, the process, if run by hand (/usr/local/ndmp/ndmpd &)
> exits immideiately.
>
> If "service ndmpd start" does anything other than execute
> /usr/local/ndmp/ndmpd,
> then it may be necessary to add a level of indirection through a shell
> script
> that runs valgrind:
>
> 1. service ndmpd stop
> 2. mv /usr/local/ndmp/ndmpd /usr/local/ndmp/ndmpd.real
> 3. cat >/usr/local/ndmp/ndmpd <<!EOF!
> #!/bin/bash
> exec valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log
> --leak-check=full /usr/local/ndmp/ndmpd.real
> !EOF!
> 4. chmod +x /usr/local/ndmp/ndmpd
> 5. service ndmpd start
>
> [PS] service ndmpd start FAILS to run using a wrapper.
>
> $ service ndmpd stop
> Stopping ndmpd:                                            [  OK  ]
>
> $ service ndmpd start
> Starting ndmpd:                                            [FAILED]
>
> $ cat /usr/local/ndmp/ndmpd
> #!/bin/bash
> #/usr/local/ndmp/ndmpd.real
> exec valgrind -v --num-callers=50 --log-file=ndmp_valgrind_04_09.log
> --leak-check=full /usr/local/ndmp/ndmpd.real
>
> $ ps -ef | grep valgrind
> root     22481     1  0 11:38 ?        00:00:00 valgrind -v
> --num-callers=50 --log-file=ndmp_valgrind_04_09.log --leak-check=full
> /usr/local/ndmp/ndmpd.real
> root     23269  4513  0 11:42 pts/4    00:00:00 grep --color=auto valgrind
>
> $ ps -ef | grep ndmpd
> root     22481     1  0 11:38 ?        00:00:00 valgrind -v
> --num-callers=50 --log-file=ndmp_valgrind_04_09.log --leak-check=full
> /usr/local/ndmp/ndmpd.real
> root     23309  4513  0 11:42 pts/4    00:00:00 grep --color=auto ndmpd
>
> As  per our observation ndmp internally starts session monitor. But in
> this case we were not able to see the session monitor and ndmp.
>
> Is there any other way to run valgrind on ndmp ?
>
> Thanks,
> Pallavi
>
> On Fri, Aug 30, 2019, 8:19 PM John Reiser <jr...@bi...> wrote:
>
>> > 1.      service ndmpd stop
>> > 2.       service ndmpd start
>> > 3.       valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log
>> --leak-check=full /usr/local/ndmp/ndmpd
>> >
>> > echo $? Returns 1 after the 3rd command.
>>
>> Does running ndmpd "by hand" work as the third step?
>> 3. /usr/local/ndmp/ndmpd &   # start in background, note the PID
>> 4. ps -ef   # does ndmpd show with the same PID as given by the shell?
>>
>> If "service ndmpd start" does anything other than execute
>> /usr/local/ndmp/ndmpd,
>> then it may be necessary to add a level of indirection through a shell
>> script
>> that runs valgrind:
>>
>> 1. service ndmpd stop
>> 2. mv /usr/local/ndmp/ndmpd /usr/local/ndmp/ndmpd.real
>> 3. cat >/usr/local/ndmp/ndmpd <<!EOF!
>> #!/bin/bash
>> exec valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log
>> --leak-check=full /usr/local/ndmp/ndmpd.real
>> !EOF!
>> 4. chmod +x /usr/local/ndmp/ndmpd
>> 5. service ndmpd start
>>
>> --
>>
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>

Re: [Valgrind-users] Running Valgrind on ndmp

[Pallavi S. <shi...@gm...>]

Hi,

Comments prefixed with [PS] below.

> 1.      service ndmpd stop
> 2.       service ndmpd start
> 3.       valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log
--leak-check=full /usr/local/ndmp/ndmpd
>
> echo $? Returns 1 after the 3rd command.

Does running ndmpd "by hand" work as the third step?
3. /usr/local/ndmp/ndmpd &   # start in background, note the PID
4. ps -ef   # does ndmpd show with the same PID as given by the shell?

[PS] In step 3, the process, if run by hand (/usr/local/ndmp/ndmpd &) exits
immideiately.

If "service ndmpd start" does anything other than execute
/usr/local/ndmp/ndmpd,
then it may be necessary to add a level of indirection through a shell
script
that runs valgrind:

1. service ndmpd stop
2. mv /usr/local/ndmp/ndmpd /usr/local/ndmp/ndmpd.real
3. cat >/usr/local/ndmp/ndmpd <<!EOF!
#!/bin/bash
exec valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log
--leak-check=full /usr/local/ndmp/ndmpd.real
!EOF!
4. chmod +x /usr/local/ndmp/ndmpd
5. service ndmpd start

[PS] service ndmpd start FAILS to run using a wrapper.

$ service ndmpd stop
Stopping ndmpd:                                            [  OK  ]

$ service ndmpd start
Starting ndmpd:                                            [FAILED]

$ cat /usr/local/ndmp/ndmpd
#!/bin/bash
#/usr/local/ndmp/ndmpd.real
exec valgrind -v --num-callers=50 --log-file=ndmp_valgrind_04_09.log
--leak-check=full /usr/local/ndmp/ndmpd.real

$ ps -ef | grep valgrind
root     22481     1  0 11:38 ?        00:00:00 valgrind -v
--num-callers=50 --log-file=ndmp_valgrind_04_09.log --leak-check=full
/usr/local/ndmp/ndmpd.real
root     23269  4513  0 11:42 pts/4    00:00:00 grep --color=auto valgrind

$ ps -ef | grep ndmpd
root     22481     1  0 11:38 ?        00:00:00 valgrind -v
--num-callers=50 --log-file=ndmp_valgrind_04_09.log --leak-check=full
/usr/local/ndmp/ndmpd.real
root     23309  4513  0 11:42 pts/4    00:00:00 grep --color=auto ndmpd

As  per our observation ndmp internally starts session monitor. But in this
case we were not able to see the session monitor and ndmp.

Is there any other way to run valgrind on ndmp ?

Thanks,
Pallavi

On Fri, Aug 30, 2019, 8:19 PM John Reiser <jr...@bi...> wrote:

> > 1.      service ndmpd stop
> > 2.       service ndmpd start
> > 3.       valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log
> --leak-check=full /usr/local/ndmp/ndmpd
> >
> > echo $? Returns 1 after the 3rd command.
>
> Does running ndmpd "by hand" work as the third step?
> 3. /usr/local/ndmp/ndmpd &   # start in background, note the PID
> 4. ps -ef   # does ndmpd show with the same PID as given by the shell?
>
> If "service ndmpd start" does anything other than execute
> /usr/local/ndmp/ndmpd,
> then it may be necessary to add a level of indirection through a shell
> script
> that runs valgrind:
>
> 1. service ndmpd stop
> 2. mv /usr/local/ndmp/ndmpd /usr/local/ndmp/ndmpd.real
> 3. cat >/usr/local/ndmp/ndmpd <<!EOF!
> #!/bin/bash
> exec valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log
> --leak-check=full /usr/local/ndmp/ndmpd.real
> !EOF!
> 4. chmod +x /usr/local/ndmp/ndmpd
> 5. service ndmpd start
>
> --
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Getting SIGKILL to work in MariaDB

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

On Wed, 2019-08-21 at 14:44 +0200, Philippe Waroquiers wrote:
> On Mon, 2019-08-12 at 15:15 +0300, Michael Widenius wrote:
> > Something like the following would be very useful:
> > VALGRIND_IGNORE_LEAKS(VALGRIND_LEAK_INDIRECT | VALGRIND_LEAK_DEFINITE...)
> See patch attached to https://bugs.kde.org/show_bug.cgi?id=411134
> This patch allows to change various command line options after
> startup, including the options telling if/how to do a leak search.
Patch pushed today to the Valgrind git repository as 3a803036.

Philippe

Re: [Valgrind-users] Running Valgrind on ndmp

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

> 1.      service ndmpd stop
> 2.       service ndmpd start
> 3.       valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log --leak-check=full /usr/local/ndmp/ndmpd
> 
> echo $? Returns 1 after the 3rd command.

Does running ndmpd "by hand" work as the third step?
3. /usr/local/ndmp/ndmpd &   # start in background, note the PID
4. ps -ef   # does ndmpd show with the same PID as given by the shell?

If "service ndmpd start" does anything other than execute /usr/local/ndmp/ndmpd,
then it may be necessary to add a level of indirection through a shell script
that runs valgrind:

1. service ndmpd stop
2. mv /usr/local/ndmp/ndmpd /usr/local/ndmp/ndmpd.real
3. cat >/usr/local/ndmp/ndmpd <<!EOF!
#!/bin/bash
exec valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log --leak-check=full /usr/local/ndmp/ndmpd.real
!EOF!
4. chmod +x /usr/local/ndmp/ndmpd
5. service ndmpd start

-- 

[Valgrind-users] Running Valgrind on ndmp

[Pallavi S. <shi...@gm...>]

Hi,


I need to run valgrind for ndmpd

I followed below steps:

1.      service ndmpd stop

2.       service ndmpd start

3.       valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log
--leak-check=full /usr/local/ndmp/ndmpd

echo $? Returns 1 after the 3rd command.


The ps –ef output does not show the valgrind process listed.

Questions:

1.       Are these correct steps to follow?


2.       How to verify that valgrind is running for ndmpd apart from logs?
Is there any steps to verify it e.g matching PIDs etc ?


System specification :


CentOS 7.2.15.11 x86_64


Valgrind 3.10.0


NDMP 2.9.29.



Thanks & Regards

Pallavi Shinde

Re: [Valgrind-users] Getting SIGKILL to work in MariaDB

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

On Mon, 2019-08-12 at 15:15 +0300, Michael Widenius wrote:
> Something like the following would be very useful:
> VALGRIND_IGNORE_LEAKS(VALGRIND_LEAK_INDIRECT | VALGRIND_LEAK_DEFINITE...)
See patch attached to https://bugs.kde.org/show_bug.cgi?id=411134
This patch allows to change various command line options after
startup, including the options telling if/how to do a leak search.

Feedback welcome ...

Philippe

Re: [Valgrind-users] Getting SIGKILL to work in MariaDB

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

On Tue, 2019-08-13 at 16:54 +0300, Michael Widenius wrote:

> I can try that at once. Thanks.
> Testing...
> hm.. It would be good to describe in README_DEVELOPERS how to generate the
> autoconfigure scripts.  Now it says one to run 'make dist', which will
> not work out of the box.
README has a section "Building and installing it".
It looks like README_DEVELOPERS should start with the same title,
and reference the README section.

> Same problem with README.solaris. Please add that one should run first
> 'autogen.sh' and then configure.
README.solaris has a pointer to the README file in the "Compilation" section,
but again that can be made more precise.

I will improve both files to add the relevant reference to README.



> Currently the kill signal is never sent to the process and the process
> continues to run.
Yes, that is the bug 409141 (fixed in the git version).

> 
> > You can avoid this interception by instead doing something like
> >    system("kill -9 me");
> > as no way valgrind will be able to intercept this.
> > (of course, me has to be the pid of the calling process).
> 
> In this case the process, in this case mysqld, needs to know who it's
> 'father' process is.
> This is a bit hard to provide to mysqld, as we only know the pid after
> valgrind is started with mysqld as an option.  Another issue is that
> mysqld doesn't know if it's run under valgrind or not and it should
> only kill it's parent if it's valgrind.
Not sure I understand, so I will explain what I understood:
You used to have in a process some lines of code sending SIGKILL
to itself, so as to commit suicide ("hard exit").
Due to bug 409141, when running under valgrind, this hangs.
You have bypassed the problem by rather sending SIGFPE, but you would
like to go back to SIGKILL.
With the fix to 409141, sending SIGKILL again really kills
the process.

The remaining problem is that SIGKILL is still causing a leak search
to be done.

To really have an "hard exit", you can replace the lines of code sending SIGKILL
by the following 3 lines:
      char cmd[1000];
      sprintf(cmd, "kill -9 %d", getpid());
      system (cmd);
With this, you really have a "hard exit".

> (Assuming I understood correctly what you meant with  calling process;
> I think you mean the 'valgrind' process in this case)
Note that when a process "runs under valgrind", there is still only one
single process, which contains both the valgrind code and the code of
the program being run "under valgrind".
So, I am not sure to understand why there is anything
special to do related to parent process when running under valgrind.

> 
> > > Please open a bug at https://bugs.kde.org/enter_bug.cgi?product=valgrind
> > > and attach a minimal test case if at all possible.
> 
> Will try to create a test case, but it's not that easy as for simple
> programs valgrind seams to pass KILL forwards.  Maybe this is only a
> problem with threaded programs.
> 
> https://www.mail-archive.com/val...@li.../msg06862.html
> seams to highlight the same problem.
As far as I can see, this message and your problem of hanging after sending
SIGKILL is the bug 409141.
And you have double checked the git version also fixes the hanging bug.
So, IMO, there is no need to have another reproducer.


> I have now tested with 10.3.16.GIT from today and did run it with
> --trace-signals=yes.
> In this case the SIGKILL is sent to the process and the process is
> killed so it looks
> like the bugs is fixed. Great!
> However one problem still reminds. After the kill, we still get a
> report of leaks which
> is not that relevant when a process is killed hard.
> Hope you will figure out a way to stop this report!
Well, the valgrind signal sending interception code has rather be explicitly
designed to do various "end of life actions" (such as run the leak search)
when a process terminates or dies, including the case where a process
sends a fatal signal to itself.

It is of course possible to implement something to really have a "hard exit"
and/or disable leak search.  What is the best feature/way to do that is not
(yet) clear to me: a more general approach such as loading a supp file
or allow to change valgrind parameters is more attractive than e.g.
a very specialised request such as VALGRIND_HARD_EXIT();

In the meantime, if my understanding is correct,
   system ("kill -9 ..."); 
as explained above gives a hard exit without allowing valgrind to
intercept the signal and do a leak search or any other closing actions.

If that does not work/is not usable, then I have missed something in
what you are trying to do.

Further comments welcome ...

Philippe

Re: [Valgrind-users] Getting SIGKILL to work in MariaDB

[Michael W. <mic...@gm...>]

Hi!

On Mon, Aug 12, 2019 at 11:59 PM Philippe Waroquiers
<phi...@sk...> wrote:
>
> On Mon, 2019-08-12 at 13:49 +0100, Tom Hughes wrote:
> > On 12/08/2019 13:15, Michael Widenius wrote:
> >
> > > The request I would like you to consider is to do one of the following:
> > > - Ensure that sending a sigkill works and in this case there should
> > > not be any valgrind leak report.

> What version of Valgrind are you using ?

valgrind-3.15.0  (latest from download page)

> I recently fixed (10 of July) in the git repository a bug with an infinite loop
> or a hang when a process sends a signal to itself.
>
> See bugs 409141 and 409367.

Sending SIGFPE works, but not SIGKILL.  I would prefer to use SIGKILL
as this used, at least in the past, to kill the process without any
leak reporting.

> So, you might test with a recent git version of Valgrind.

I can try that at once. Thanks.
Testing...
hm.. It would be good to describe in README_DEVELOPERS how to generate the
autoconfigure scripts.  Now it says one to run 'make dist', which will
not work out of the box.
Same problem with README.solaris. Please add that one should run first
'autogen.sh' and then configure.

See more about this at end of email:

> > > - Add an api call where we could specify that we don't want any leak
> > > reports from now on.  If this would exist then I could call this when
> > > we are about to send the SIGFPE/SIGKILL signal to the server.
> A stackoverflow discussion led to a suggestion to have a
> monitor command/client request to load a new suppression file.
> This would allow to load a supp file suppressing all leaks.

Yes, could be useful but then the binary would need to know where the
suppression files are
, which is harder for dynamic test system that starts the mysqld
binary with different patch depending on configuration.

> Allowing to load a suppression file via a client request might be useful
> in other circumstances (the stackoverflow case was to avoid any leak
> search when a program fails between a fork and an exec, but it
> could be used to suppress flexibly whatever kind of errors and/or
> automatically load a supp file e.g. when loading a shared lib).

Yes, I agree that for many programs that would be useful. However for
any program that just need a way to kill itself 'hard' and not get any
more reports from valgrind that is a bit of
overkill.

> Alternatively, the only reason why valgrind can do a leak search
> when your process calls "kill (me, 9);"
> is that valgrind is intercepting the syscall and does a leak
> search before really self-killing.

Currently the kill signal is never sent to the process and the process
continues to run.

> You can avoid this interception by instead doing something like
>    system("kill -9 me");
> as no way valgrind will be able to intercept this.
> (of course, me has to be the pid of the calling process).

In this case the process, in this case mysqld, needs to know who it's
'father' process is.
This is a bit hard to provide to mysqld, as we only know the pid after
valgrind is started with mysqld as an option.  Another issue is that
mysqld doesn't know if it's run under valgrind or not and it should
only kill it's parent if it's valgrind.
(Assuming I understood correctly what you meant with  calling process;
I think you mean the 'valgrind' process in this case)

> > Please open a bug at https://bugs.kde.org/enter_bug.cgi?product=valgrind
> > and attach a minimal test case if at all possible.

Will try to create a test case, but it's not that easy as for simple
programs valgrind seams to pass KILL forwards.  Maybe this is only a
problem with threaded programs.

https://www.mail-archive.com/val...@li.../msg06862.html
seams to highlight the same problem.

currently one can see this in MariaDB 10.4 from git by running:
mysql-test-run --valgrind innodb.alter_copy

which I am agree is not a simple test cases.  If I can't figure a good
workaround for MariaDB
I will try to create a simpler test case and report it properly.

> > Also the output of running valgrind with --trace-signals=yes would be
> > a good thing to provide.

I have now tested with 10.3.16.GIT from today and did run it with
--trace-signals=yes.
In this case the SIGKILL is sent to the process and the process is
killed so it looks
like the bugs is fixed. Great!
However one problem still reminds. After the kill, we still get a
report of leaks which
is not that relevant when a process is killed hard.
Hope you will figure out a way to stop this report!

Regards,
Monty

Re: [Valgrind-users] Getting SIGKILL to work in MariaDB

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

On Mon, 2019-08-12 at 13:49 +0100, Tom Hughes wrote:
> On 12/08/2019 13:15, Michael Widenius wrote:
> 
> > The request I would like you to consider is to do one of the following:
> > - Ensure that sending a sigkill works and in this case there should
> > not be any valgrind leak report.
What version of Valgrind are you using ?

I recently fixed (10 of July) in the git repository a bug with an infinite loop
or a hang when a process sends a signal to itself.

See bugs 409141 and 409367.

So, you might test with a recent git version of Valgrind.

> > - Add an api call where we could specify that we don't want any leak
> > reports from now on.  If this would exist then I could call this when
> > we are about to send the SIGFPE/SIGKILL signal to the server.
A stackoverflow discussion led to a suggestion to have a
monitor command/client request to load a new suppression file.
This would allow to load a supp file suppressing all leaks.

Allowing to load a suppression file via a client request might be useful
in other circumstances (the stackoverflow case was to avoid any leak
search when a program fails between a fork and an exec, but it
could be used to suppress flexibly whatever kind of errors and/or
automatically load a supp file e.g. when loading a shared lib).

Alternatively, the only reason why valgrind can do a leak search
when your process calls "kill (me, 9);"
is that valgrind is intercepting the syscall and does a leak
search before really self-killing.

You can avoid this interception by instead doing something like
   system("kill -9 me");
as no way valgrind will be able to intercept this.
(of course, me has to be the pid of the calling process).

Philippe



> 
> Please open a bug at https://bugs.kde.org/enter_bug.cgi?product=valgrind
> and attach a minimal test case if at all possible.
> 
> Also the output of running valgrind with --trace-signals=yes would be
> a good thing to provide.
> 
> Tom
> 

Re: [Valgrind-users] Getting SIGKILL to work in MariaDB

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

On 12/08/2019 13:15, Michael Widenius wrote:

> The request I would like you to consider is to do one of the following:
> - Ensure that sending a sigkill works and in this case there should
> not be any valgrind leak report.
> - Add an api call where we could specify that we don't want any leak
> reports from now on.  If this would exist then I could call this when
> we are about to send the SIGFPE/SIGKILL signal to the server.

Please open a bug at https://bugs.kde.org/enter_bug.cgi?product=valgrind
and attach a minimal test case if at all possible.

Also the output of running valgrind with --trace-signals=yes would be
a good thing to provide.

Tom

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

[Valgrind-users] Getting SIGKILL to work in MariaDB

[Michael W. <mic...@gm...>]

Hi!

I am the creator of MySQL and MariaDB and a valgrind user since a LONG
time!  valgrind has been used to verify the integrity of MySQL since
the very early times of valgrind!

I have a small request to solve a small problem with valgrind in MariaDB:

To be able to test recovery during testing, our test system takes down
the mysqld server process hard and schedules a restart of the server.

We used to do that by sending sigkill internally in the the server to
itself and then the test waits for the server to restart and then the
test continues.

I noticed recently that when running the server under valgrind, the
sigkill was ignored and thus the test stalled. (I think this worked
with some earlier version of valgrind, but I am not sure about this)

I have now fixed this by sending a SIGFPE signal instead and setting
an internal variable to mark that we shouldn't write to the log that
the server died (as the test system who examines the logs would think
something went wrong).

The problem is that when the server dies hard with SIGFPE, the memtool
writes out the leaks and the test system thinks something is wrong.

The request I would like you to consider is to do one of the following:
- Ensure that sending a sigkill works and in this case there should
not be any valgrind leak report.
- Add an api call where we could specify that we don't want any leak
reports from now on.  If this would exist then I could call this when
we are about to send the SIGFPE/SIGKILL signal to the server.

Something like the following would be very useful:
VALGRIND_IGNORE_LEAKS(VALGRIND_LEAK_INDIRECT | VALGRIND_LEAK_DEFINITE...)

Regards,
Monty

[Valgrind-users] Valgrind with CUDA: noted but unhandled ioctl with no size/direction hints

[Jiading G. <zi...@gm...>]

Hi everyone.

I'm trying Valgrind on a simple CUDA program for CPU memory check (It
worked for GPU memcheck when using cuda-memcheck):

```
#include <stdlib.h>

int main()
{
  void *dp = NULL;
  cudaMalloc(&dp, 1024);
  cudaFree(dp);

  void *p = NULL;
  p = malloc(1024);
  free(p);

  cudaDeviceReset();
  return 0;
}
```

The program hangs with many `noted but unhandled ioctl with no
size/direction hints` warnings.

```
$ nvcc prog.cu
$ valgrind ./a.out
==61517== Memcheck, a memory error detector
==61517== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==61517== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==61517== Command: ./a.out
==61517==
==61517== Warning: noted but unhandled ioctl 0x30000001 with no
size/direction hints.
==61517==    This could cause spurious value errors to appear.
==61517==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: noted but unhandled ioctl 0x27 with no size/direction hints.
==61517==    This could cause spurious value errors to appear.
==61517==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: noted but unhandled ioctl 0x7ff with no size/direction hints.
==61517==    This could cause spurious value errors to appear.
==61517==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: noted but unhandled ioctl 0x25 with no size/direction hints.
==61517==    This could cause spurious value errors to appear.
==61517==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: noted but unhandled ioctl 0x37 with no size/direction hints.
==61517==    This could cause spurious value errors to appear.
==61517==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: noted but unhandled ioctl 0x17 with no size/direction hints.
==61517==    This could cause spurious value errors to appear.
==61517==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: set address range perms: large range [0x200000000,
0x300200000) (noaccess)
==61517== Warning: set address range perms: large range [0x7798000,
0x27797000) (noaccess)
==61517== Warning: set address range perms: large range
[0x10006000000, 0x10106000000) (noaccess)
==61517== Warning: noted but unhandled ioctl 0x19 with no size/direction hints.
==61517==    This could cause spurious value errors to appear.
==61517==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: set address range perms: large range
[0x10106000000, 0x10206000000) (noaccess)
==61517== Warning: noted but unhandled ioctl 0x21 with no size/direction hints.
==61517==    This could cause spurious value errors to appear.
==61517==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==61517== Warning: noted but unhandled ioctl 0x1b with no size/direction hints.
==61517==    This could cause spurious value errors to appear.
==61517==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
```

I'm also follwing this question[0] to generate Valgrind suppressions,
the program hangs again with same warnings. How can I use Valgrind
with CUDA correctly? Thanks in advance.

I'm using Ubuntu 18.04 + CUDA 9.1 + Valgrind 3.13.0.

Best regards,
Jiading Guo

[0]: https://stackoverflow.com/questions/20593450/valgrind-and-cuda-are-reported-leaks-real

Re: [Valgrind-users] How to instrument a custom allocator properly?

[Tomas V. <tv...@fu...>]

On 8/6/19 11:47 AM, Ruurd Beerstra wrote:
> Hi,
> 
> We have a custom allocator which I have instrumented with VALGRIND 
> macro’s so we can run our software under valgrind and detect memory 
> abuse and leaks.
> 
> Works great, and has done so for many years now.
> 
> That allocator used to use sbrk() to get the raw memory in large chunks, 
> and then uses VALGRIND_MALLOCLIKE_BLOCK when it doled out smaller chunks 
> to the applications.
> 
> But sbrk() does not work well when a single application uses multiple 
> allocators, and our software now links with 3^rd party code which has 
> its own ideas about allocation.
> 
> That caused problems and instability.
> 
> So, our custom allocator now uses the system ‘malloc()’ instead of 
> sbrk() to allocate large chunks, which solves the interference problems 
> between allocators.
> That stabilized the software.
> 
> However, now valgrind gets confused: It sees overlapping mallocs() (the 
> smaller VALGRIND_MALLOCLIKE_BLOCKS are within the large chunks allocated 
> with malloc()).
> 
> I’m now struggling with the instrumentation in our allocator but I can’t 
> get it to work.
> 
> The error reports I get are just plain wrong: It says stuff like:
> 
> 2019-08-06 00:57:20: ==30298== Invalid read of size 1
> 
> 2019-08-06 00:57:20: ==30298==    at 0x4059CF: main (valgrindTest.c:126)
> 
> 2019-08-06 00:57:20: ==30298==  Address 0x5e43878 is 72 bytes inside a 
> block of size 65,536 alloc'd
> 
> 2019-08-06 00:57:20: ==30298==    at 0x4C29DDB: malloc 
> (vg_replace_malloc.c:299)
> 
> 2019-08-06 00:57:20: ==30298==    by 0x42DE98: mal_own_sbrk 
> (al_alloc.c:4251)
> 
> 2019-08-06 00:57:20: ==30298==    by 0x42E7E5: mal_inc_space 
> (al_alloc.c:4442)
> 
> 2019-08-06 00:57:20: ==30298==    by 0x4290E3: _mal_allocater 
> (al_alloc.c:1915)
> 
> 2019-08-06 00:57:20: ==30298==    by 0x428235: mal_allocater_c 
> (al_alloc.c:1608)
> 
> 2019-08-06 00:57:20: ==30298==    by 0x426C10: vmal_reserve_id 
> (al_alloc.c:1131)
> 
> 2019-08-06 00:57:20: ==30298==    by 0x42690B: mal_reserve_id 
> (al_alloc.c:999)
> 
> 2019-08-06 00:57:20: ==30298==    by 0x405495: main (valgrindTest.c:46)
> 
> So the offending byte is always in one of the “outer” malloced block of 
> 64KB, which is not what I want.
> The stack is that of the allocator itself, also not what I want (the 
> function is still called mal_own_sbrk, but that is  a misnomer now).
> 

I'm not sure what the problem is (I've seen these "invalid read" reports 
in various situations, e.g. when accessing "padding" space in a struct, 
or when accessing areas marked as VALGRIND_MAKE_MEM_NOACCESS).

But maybe take a look at this:

https://github.com/postgres/postgres/blob/master/src/backend/utils/mmgr/aset.c

That's a custom allocator used by PostgreSQL, using pretty much exactly 
the same design like you do (based on malloc etc.), and it's heavily 
valgrind-enabled. And it works quite fine. So maybe you could look at 
what we're doing there and copy the instrumentation ...

> Another example:
> 
> ==16897==  Uninitialised value was created by a stack allocation
> 
> ==16897==    at 0x492748: evt_get_3glLong_event (evt_fun.c:388)
> 
> ==16897==
> 
> The memory in question here is allocated using our allocator (and not on 
> the stack, so the reports is just wrong).
> Secondly, the rest of call stack is missing. Seems valgrind is confused 
> here.
> 

If I had to guess, I'd say this is complaining about the local variable 
not being initialized before use, not the memory allocated on heap.

regards
T.

[Valgrind-users] How to instrument a custom allocator properly?

[Ruurd B. <Ruu...@in...>]

Hi,

We have a custom allocator which I have instrumented with VALGRIND macro's so we can run our software under valgrind and detect memory abuse and leaks.
Works great, and has done so for many years now.
That allocator used to use sbrk() to get the raw memory in large chunks, and then uses VALGRIND_MALLOCLIKE_BLOCK when it doled out smaller chunks to the applications.
But sbrk() does not work well when a single application uses multiple allocators, and our software now links with 3rd party code which has its own ideas about allocation.
That caused problems and instability.
So, our custom allocator now uses the system 'malloc()' instead of sbrk() to allocate large chunks, which solves the interference problems between allocators.
That stabilized the software.

However, now valgrind gets confused: It sees overlapping mallocs() (the smaller VALGRIND_MALLOCLIKE_BLOCKS are within the large chunks allocated with malloc()).
I'm now struggling with the instrumentation in our allocator but I can't get it to work.
The error reports I get are just plain wrong: It says stuff like:

2019-08-06 00:57:20: ==30298== Invalid read of size 1
2019-08-06 00:57:20: ==30298==    at 0x4059CF: main (valgrindTest.c:126)
2019-08-06 00:57:20: ==30298==  Address 0x5e43878 is 72 bytes inside a block of size 65,536 alloc'd
2019-08-06 00:57:20: ==30298==    at 0x4C29DDB: malloc (vg_replace_malloc.c:299)
2019-08-06 00:57:20: ==30298==    by 0x42DE98: mal_own_sbrk (al_alloc.c:4251)
2019-08-06 00:57:20: ==30298==    by 0x42E7E5: mal_inc_space (al_alloc.c:4442)
2019-08-06 00:57:20: ==30298==    by 0x4290E3: _mal_allocater (al_alloc.c:1915)
2019-08-06 00:57:20: ==30298==    by 0x428235: mal_allocater_c (al_alloc.c:1608)
2019-08-06 00:57:20: ==30298==    by 0x426C10: vmal_reserve_id (al_alloc.c:1131)
2019-08-06 00:57:20: ==30298==    by 0x42690B: mal_reserve_id (al_alloc.c:999)
2019-08-06 00:57:20: ==30298==    by 0x405495: main (valgrindTest.c:46)

So the offending byte is always in one of the "outer" malloced block of 64KB, which is not what I want.
The stack is that of the allocator itself, also not what I want (the function is still called mal_own_sbrk, but that is  a misnomer now).
Another example:

==16897==  Uninitialised value was created by a stack allocation
==16897==    at 0x492748: evt_get_3glLong_event (evt_fun.c:388)
==16897==

The memory in question here is allocated using our allocator (and not on the stack, so the reports is just wrong).
Secondly, the rest of call stack is missing. Seems valgrind is confused here.

I tried to lie to valgrind by using VALGRIND_FREELIKE_BLOCK immediately after the malloc() that replaces sbrk(). No joy, it dumps core on me.
I tried to find a way to tell valgrind that it should close its eyes for a moment while doing the low-level malloc(), but can't find a way to accomplish that.

So I ask the collected wisdom of this mailing list: If I have a custom allocator that uses malloc() to get large chunks and then doles out smaller chunks to the application, how do I make that work with valgrind memcheck  so it sees only the allocations performed by the "outer" allocator and not the inner one?

                Thank you in advance,
                Ruurd Beerstra.







Ruurd Beerstra, Principal Software Engineer
mobile: +31 622427478
Ruu...@in...<mailto:Ruu...@in...>  |  http://www.infor.com<http://www.infor.com/>

[Valgrind-users] Capability of handling programs with large BSS and data segments

[João M. S. S. <joa...@gm...>]

Hi,

Is Valgrind now able to load programs with really large BSS and data 
segments (4 GB)?

I have asked this before: 
https://www.mail-archive.com/search?l=val...@li...&q=subject:%22Re%5C%3A+%5C%5BValgrind%5C-users%5C%5D+failed+in+UME+with+error+22%22&o=newest

But now I was wondering if anything changed that allows me to run 
Valgrind on this program. Changing the configuration and building 
Valgrind (as suggested in the archive thread) does not work for such 
large segments (only for ~1,5 GB, the program has grown to 4 GB).

Thanks.

-- 
João M. S. Silva

Re: [Valgrind-users] Can't see the actual vars

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

> ==3232== Syscall param stat64(file_name) points to uninitialised byte(s)

file_name is the first (leftmost) parameter.

> ==3232==    at 0x49FD6B8: _xstat (xstat.c:48)
> ==3232==    by 0x41F23: stat (stat.c:51)
> ==3232==    by 0x1EC93: getList (util.c:1379)

 > Looking at line 1379 from util.c:
 > if (!stat(listfile, &statbuf))

> ==3232==    by 0x18E0F: _get_var (ngr.c:3868)
> ==3232==    by 0x19F33: get_var (ngr.c:4049)
> ==3232==    by 0xBB4F: main (daemon.c:346)
> ==3232==  Address 0x7d87ba8c is on thread 1's stack
> ==3232==  in frame #2, created by getList (util.c:1300)
> ==3232==  Uninitialised value was created by a stack allocation
> ==3232==    at 0x1E55C: getList (util.c:1300)

> listfile does exist.

What is the declaration of listfile?  Is it an array, a pointer, ...?
It would be helpful to print its value:
     fprintf(stderr, "\nlistfile='%s'\n", listfile);
just before the stat() call.

> statbuf however, is simply defined as: struct stat statbuf;
> It's not initialized by memset or something, is that what valgrind complains about?

No; the first line of the complaint indicates that the complaint
is about the file_name, the first parameter, which is read by stat().
The documentation (run the shell command "man 2 stat") explains that
the second argument is output-only.  The operating system kernel
writes to [nearly] all the statbuf, and reads none of it.

If the original presentation captures all the important information,
then it will be easy to construct a small stand-alone test case
that triggers the complaint in question.  Please try that.

[Valgrind-users] Can't see the actual vars

[Reinoud K. <rei...@gm...>]

Hello Everyone,
I am seeing messages like this:
--3232-- REDIR: 0x49bf990 (libc.so.6:strncat) redirected to 0x482d71c
(strncat)
==3232== Syscall param stat64(file_name) points to uninitialised byte(s)
==3232==    at 0x49FD6B8: _xstat (xstat.c:48)
==3232==    by 0x41F23: stat (stat.c:51)
==3232==    by 0x1EC93: getList (util.c:1379)
==3232==    by 0x18E0F: _get_var (ngr.c:3868)
==3232==    by 0x19F33: get_var (ngr.c:4049)
==3232==    by 0xBB4F: main (daemon.c:346)
==3232==  Address 0x7d87ba8c is on thread 1's stack
==3232==  in frame #2, created by getList (util.c:1300)
==3232==  Uninitialised value was created by a stack allocation
==3232==    at 0x1E55C: getList (util.c:1300)

Looking at line 1379 from util.c:
if (!stat(listfile, &statbuf))

listfile does exist.
statbuf however, is simply defined as: struct stat statbuf;
It's not initialized by memset or something, is that what valgrind
complains about? Thanks,
Reinoud.

Re: [Valgrind-users] Mencheck not giving detailed info on routines in Shared Libraries:

[robert s. <rbr...@gm...>]

You were correct! Somehow my environment setup messed up the
configure/build/execution(??) of Valgrind 3.15. It now works correctly with
--save-debuginfo=yes !
Thanks ;-)

On Wed, Jul 10, 2019 at 9:25 AM robert somerville <rbr...@gm...>
wrote:

> It actually was compiled with debug info ( as noted,  Totalview works fine
> ). I have tried --keep-debuginfo=yes, but no joy ...
> I am investigating whether dlclose was called ...
>
> On Wed, Jul 10, 2019 at 9:22 AM Tom Hughes <to...@co...> wrote:
>
>> On 10/07/2019 16:17, Julian Seward wrote:
>> >
>> >  > Valgrind-3.13 (actually I compiled 3.15, but it says 3.13 with
>> Valgrind
>> >  > --version)
>> >
>> > In that case you're not running the version you compiled.
>> >
>> > Try running 3.15 and give it the flag --keep-debuginfo=yes.  Does that
>> > help?
>>
>> If it was an so that had been unloaded then I don't think it would
>> even show the name would it? So I'm not sure --keep-debuginfo=yes
>> will help...
>>
>> Tom
>>
>> --
>> Tom Hughes (to...@co...)
>> http://compton.nu/
>>
>

Re: [Valgrind-users] Mencheck not giving detailed info on routines in Shared Libraries:

[robert s. <rbr...@gm...>]

It actually was compiled with debug info ( as noted,  Totalview works fine
). I have tried --keep-debuginfo=yes, but no joy ...
I am investigating whether dlclose was called ...

On Wed, Jul 10, 2019 at 9:22 AM Tom Hughes <to...@co...> wrote:

> On 10/07/2019 16:17, Julian Seward wrote:
> >
> >  > Valgrind-3.13 (actually I compiled 3.15, but it says 3.13 with
> Valgrind
> >  > --version)
> >
> > In that case you're not running the version you compiled.
> >
> > Try running 3.15 and give it the flag --keep-debuginfo=yes.  Does that
> > help?
>
> If it was an so that had been unloaded then I don't think it would
> even show the name would it? So I'm not sure --keep-debuginfo=yes
> will help...
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>