how do i valgrind memcheck on every instance of Process without starting it via valgrind command options

Question

how do i do a valgrind memcheck on every instance of Process without starting it via valgrind command options.

Is there a way to keep the monitoring options saved on a process rather than starting up the process every-time with valgrind command?

In Microsoft Application Verifier if an application is specified to be monitored, then any number of instances of that application gets monitored, whether its a child process or started otherwise.

Any ideas to do same in Valgrind?

I have tried --trace-children=yes option of valgrind memcheck ...but my application xyz signals another application zzz to start a new intance of xyz(process), which i want to analyze. in this case, valgrind exits when xyz finishes signalling zzz. it does not follow up on what process zzz started.

Thanks, Vijay

Answer 1

IIRC, Valgrind must execute the application because it alters the read-only symbols to replace common library functions like malloc and so on.

This means you can't attach memcheck to an already running process because it can't alter that section of the program in memory (and it would probably corrupt running state).

There are probably other reasons too. A quick google suggests that you can't attach memcheck to a running process too. As suggested, you can wrap your executables in a bash script such as. So if program myprog creates new processes of newprog then do:

]$ mv /path/to/myprog /path/to/newprog

then

#!/bin/bash
valgrind (options) /path/to/newprog $@

and call it myprog the $@ ensures arguments are passed. Then when your program creates a new process, using myprog -a b -c d then it is wrapped in valgrind.

This only applies to certain C calls like execve() and others, whereas other obscure ways of creating processes may not take advantage of the wrapping.

If I am wrong, it would be a good thing to know :)

Answer 2

Can you wrap xyz either in a batch file or another executable that launches it within valgrind?

In other words, rename xyz to run_me_under_valgrind, then create a new xyz that launches the original run_me_under_valgrind under valgrind.

Answer 3

Regarding wrapper executables, I've landed up with the following script for PostgreSQL. (I've trimmed out various postgres-specific parts like discovering the supplied valgrind suppressions file).

#!/bin/bash
set -e -u -x

# Pop top two elements from path; the first is added by pg_regress
# and the next is us.
function join_by { local IFS="$1"; shift; echo "$*"; }
IFS=':' read -r -a PATHA <<< "$PATH"
export PATH=$(join_by ":" "${PATHA[@]:2}")

NEXT_POSTGRES=$(which postgres)
if [ "${NEXT_POSTGRES}" -ef "./valgrind/postgres" ]; then
    echo "ERROR: attempt to execute self"
    exit 1
fi

echo "Running ${NEXT_POSTGRES} under Valgrind"

valgrind --leak-check=full --show-leak-kinds=definite,possible \
    --gen-suppressions=all --verbose --time-stamp=yes  \
    --log-file=valgrind-$$-%p.log --trace-children=yes \
    --track-origins=yes --read-var-info=yes --malloc-fill=8f \
    --free-fill=9f --num-callers=30 postgres "$@"

Note the PATH manipulation to ensure that we don't try to exec postgres from the same place again. In this case it was necessary that the wrapper script also be named exactly postgres so I had to make sure it didn't recursively execute its self.

An alternative is to use whatis -a to find the next executable in the path and run it directly. But I found that caused other issues for my use case.

---

BTW, if you get an error like

   valgrind: mmap(0x58000000, 2347008) failed in UME with error 22 (Invalid argument).
   valgrind: this can be caused by executables with very large text, data or bss segments.

... then it's quite possible you're trying to run valgrind under valgrind by mistake.