While working with Valgrind tool, i need to log the details produced by valgrind tool. How can I accomplish that? I tried something like,
valgrind a.out | test
and
valgrind a.out > test
It gave just the program's output and not the valgrind memory error,leak information. Even i am getting like this if the program requires no user interaction (i.e. giving input). If the program need user input even that thing itself won't work.
How can I do this?
valgrind --log-file="filename"
By default, Valgrind writes its output to stderr. So you need to do something like:
valgrind a.out > log.txt 2>&1
Alternatively, you can tell Valgrind to write somewhere else; see http://valgrind.org/docs/manual/manual-core.html#manual-core.comment (but I've never tried this).
You can also set the options --log-fd if you just want to read your logs with a less.
For example :
valgrind --log-fd=1 ls | less
In addition to the other answers (particularly by Lekakis), some string replacements can also be used in the option --log-file= as elaborated in the Valgrind's user manual.
Four replacements were available at the time of writing:
%p: Prints the current process ID
valgrind --log-file="myFile-%p.dat" <application-name>
%n: Prints file sequence number unique for the current process
valgrind --log-file="myFile-%p-%n.dat" <application-name>
%q{ENV}: Prints contents of the environment variable ENV
valgrind --log-file="myFile-%q{HOME}.dat" <application-name>
%%: Prints %
valgrind --log-file="myFile-%%.dat" <application-name>
Related
I am developing a Qt application in Python. It uses a resource file, which needs to be compiled. I am using autotools to manage compilation and installation of my projects.
Now, in order for the resource file to be usable by the application, it needs to be compiled with a certain version of the compilation program (pyrcc). I can get the version by putting the output of pyrcc -version in a variable in configure.ac. But then, I don't know how to check whether the string pyrcc5 is present in the output. If it is not present, I want to tell the user that his PyRCC programm has the wrong version, and abort configure.
Additionally, I would like to avoid the need of an extra variable for the program output, but instead do it like this (Pseudo code):
if "pyrcc5" not in output of "pyrcc -version":
say "pyrcc has wrong version"
exit 1
How can I do this ?
When writing a configure.ac for Autoconf, always remember that you are basically writing a shell script. Autoconf provides a host of macros that afford you a lot of leverage, but you can usually at least get an idea about basic "How can I do X in Autoconf?" questions by asking instead "How would I do X in a portable shell script?"
In particular, for ...
I would like to avoid the need of an extra variable for the program
output, but instead do it like this (Pseudo code):
if "pyrcc5" not in output of "pyrcc -version":
say "pyrcc has wrong version"
exit 1
... the usual tool for a portable shell script to use for such a task is grep, and, happily, the easiest way to apply it to the task does not require an intermediate variable. For example, this implements exactly your pseudocode (without emitting any extraneous messaging to the console):
if ! pyrcc -version | grep pyrcc5 >/dev/null 2>/dev/null; then
echo "pyrcc has wrong version"
exit 1
fi
That pipes the output of pyrcc -version into grep, and relies on the fact that grep exits with a success status if and only if it finds any matches.
You could, in fact, put exactly that in your configure.ac, but it would be more idiomatic to
Use the usual Autoconf mechanisms to locate pyrcc and grep, and to use the versions discovered that way;
Use the Autoconf AS_IF macro to write the if construct, instead of writing it literally;
Use standard Autoconf mechanisms for emitting a "checking..." message and reporting on its result; and
Use the standard Autoconf mechanism for outputting a failure message and terminating.
Of course, all of that makes the above considerably more complex, but also more flexible and portable. It might look like this:
AC_ARG_VAR([PYRCC], [The name or full path of pyrcc. Version 5 is required.])
# ...
AC_PROG_GREP
AC_CHECK_PROGS([PYRCC], [pyrcc5 pyrcc], [])
AS_IF([test "x${PYRCC}" = x],
[AC_MSG_ERROR([Required program pyrcc was not found])])
# ...
AC_MSG_CHECKING([whether ${PYRCC} has an appropriate version])
AS_IF([! pyrcc -version | grep pyrcc5 >/dev/null 2>/dev/null], [
AC_MSG_RESULT([no])
AC_MSG_ERROR([pyrcc version 5 is required, but ${PYRCC} is a different version])
], [
AC_MSG_RESULT([yes])
])
In addition to portability and conventional Autoconf progress messaging, that also gets the builder a way to specify a particular pyrcc executable to configure (by setting variable PYRCC in its environment), documents that in configure's help text, and exports PYRCC as a make variable.
Oh, and I snuck in a check for pyrcc under the name pyrcc5, too, though I don't know whether that's useful in practice.
The final result no longer looks much like the shell script fragment I offered first, I grant. But again, the pure shell script fragment could be used as is, and also, the fully Autoconfiscated version is derived directly from the pure script.
When I run sudo bpftool prog show I get the following output
39: socket_filter name bpfprog1 tag e29cda32ba011d7f gpl
loaded_at 2019-09-08T14:21:57+0200 uid 1000
xlated 248B jited 169B memlock 4096B map_ids 30
but If I try to get the program jitted output with the following command
sudo bpftool prog dump jited tag e29cda32ba011d7f
I get an error message, as reported below:
Error: can't get prog info (3): Bad address
QUESTION: what am I doing wrong? XD
You most certainly use a bpftool version compiled from Linux 4.20 or older, and hit a bug that was fixed in version 5.0. Update bpftool, and dumping programs by tags should work again.
As a side note, I usually use program IDs or pinned path, as I find it more useful to retrieve the program I want. Depending on your use case, tags might make sense, especially if you often load the same programs without changes (so you would be sure to keep the same tags) and do not have them pinned.
I have a command
my $output = `somecommand parm1 parm2`;
When I try to run this Perl script I get the message
Can't exec "somecommand" at .....
It seems it is not seeing anything past the first space in between the backticks. I have a friend who runs this in a different environment and it runs fine.
What could I have in my environment that would cause this? I am running Perl v5.20 but so is my friend.
Perl's not ignoring the command parameters, it's just mentioning only the part of the command that it has a problem with -- it can't find somecommand
Whatever your somecommand is, it's not a shell command and it's not in a directory listed in your PATH variable
Change PATH to add its location to the end and it will work for you. You can do that system-wide or you dan modify it temporarily in your Perl code by manipulating $ENV{PATH} before you run the command
First, some background. I'm trying to use cvs annotate within a Perl script invoked from a ksh command line to find out who's using bad hex constants in their source code and dole out justice appropriately. I'd like to use stdout for this program strictly for my own structured output, so I can pipe it to a file or to other programs. But, every call to cvs annotate results in a diagnostic message being printed to the console. It takes the form of:
Annotations for <filename>
***********
It's mucking up my stdout! I played around with annotate on the command line, and I figured that these diagnostic messages were coming from stderr, because running this command directly in ksh:
cvs annotate <filename> 1>yay.txt 2>boo.txt
correctly puts the desired annotated output into yay.txt and the diagnostics into boo.txt. However, things get weirder when I try to run this from within a perl script using backticks.
$muhstring = `cvs annotate $filename 2>boo.txt`;
The desired annotated output does appear in $muhstring, but the diagnostics still get printed to the command line, and boo.txt is created as an empty file. There's an admittedly old post on perlmonks.org that says this syntax should work as written. So, what's the deal? Is this a CVS quirk, have I misread the post, or have things changed since 1999? Or is it something else?
Edit: So, it is not, in fact, mucking up stdout. I tried this in ksh:
perl findbadhexowners.pl badhex.txt > out.txt
and the diagnostic messages still printed to the console, but out.txt only contains the annotations. This is fine for my purposes, and I can continue with other code.
That said, it seems like Perl and cvs specifically are interacting a little strangely, especially considering that redirection in ksh works fine and redirection in Perl for other commands like cd works fine - for example, in Perl
`cd nonexistentDir 1>stdout.txt 2>stderr.txt`;
gives the expected output in both stdout.txt and stderr.txt. It's only using cvs annotate from within Perl that produces this problem.
I have a Perl program written by someone else. When I run it, it silently exits without writing anything to the logfile. Is there a way I can run this Perl program step by step, line by line by the interpreter and thus get to see where it terminates?
Yes, there is the Perl debugger which you can invoke with perl -d.
Documentation can be found in perldoc perldebug and perldoc perldebtut.
Probably the most useful commands would be:
s - step into current line.
n - step over current line.
r - step out of current function.
p <expr> - print the expression.
b <line|subnm> - sets a breakpoint
T - produce a stack trace.
c [<line|subnm>] - continue running with optional one-time breakpoint.
h - help (for other commands).
Hachi has the answer. Use the Perl debugger by running perl with the -d flag. For information on how to use the debugger past starting it, see the Perl Debugging Tutorial.
There is a Perl module called "ptkdb" which is a standalone Perl interactive debugger. It works using the Tcl/Tk GUI, so you'll need that, too.
Depending on your OS you'll need to add some required modules.
Invoke it using
perl -d:ptkdb <your script>
If running some Unix/Linux system, you also need an X server.
There are two ways. The first is the one which Hachi and llioin already gave which is using the command-line switch "-d".
Or use an IDE. I am tried and used Komodo IDE which works like charm.