How do I use Valgrind utility with my simple C program in Linux?
Suppose my executable is a.out. How to check any leaks in my program with Valgrind.
I basically want to know how to use Valgrind.
It is as simple as:
$ valgrind ./a.out
if your a.out is in the current working directory.
In case you have got Valgrind already installed you can learn about the usage running:
$ valgrind --help.
Unfortunately, there is no entry manual entry for Valgrind when running man valgrind.
Related
I use the following command to run valgrind. But the ./main's output will be mixed with the output of valgrind. I want to keep valgrind's output to stdout. Is there a way to ignore ./main's stdout? Thanks.
valgrind --tool=callgrind --dump-instr=yes --collect-jumps=yes --callgrind-out-file=/dev/stdout ./main
You can use /proc/$$/fd/1 to refer to the original standard output in the calling shell, before the redirection, like this:
valgrind --tool=callgrind --callgrind-out-file=/proc/$$/fd/1 /bin/echo foo > /dev/null
If the system does not support /proc/$$/fd but has /dev/fd (for the current process), this might work (within a script, using bash):
exec {old_stdout}>&1
valgrind --tool=callgrind --callgrind-out-file=/dev/fd/$old_stdout /bin/echo foo > /dev/null
I'm trying to debug a compilation problem, but I cannot seem to get GCC (or maybe it is make??) to show me the actual compiler and linker commands it is executing.
Here is the output I am seeing:
CCLD libvirt_parthelper
libvirt_parthelper-parthelper.o: In function `main':
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:102: undefined reference to `ped_device_get'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:116: undefined reference to `ped_disk_new'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:122: undefined reference to `ped_disk_next_partition'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:172: undefined reference to `ped_disk_next_partition'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:172: undefined reference to `ped_disk_next_partition'
collect2: ld returned 1 exit status
make[3]: *** [libvirt_parthelper] Error 1
What I want to see should be similar to this:
$ make
gcc -Wall -c -o main.o main.c
gcc -Wall -c -o hello_fn.o hello_fn.c
gcc main.o hello_fn.o -o main
Notice how this example has the complete gcc command displayed. The above example merely shows things like "CCLD libvirt_parthelper". I'm not sure how to control this behavior.
To invoke a dry run:
make -n
This will show what make is attempting to do.
Build system independent method
make SHELL='sh -x'
is another option. Sample Makefile:
a:
#echo a
Output:
+ echo a
a
This sets the special SHELL variable for make, and -x tells sh to print the expanded line before executing it.
One advantage over -n is that is actually runs the commands. I have found that for some projects (e.g. Linux kernel) that -n may stop running much earlier than usual probably because of dependency problems.
One downside of this method is that you have to ensure that the shell that will be used is sh, which is the default one used by Make as they are POSIX, but could be changed with the SHELL make variable.
Doing sh -v would be cool as well, but Dash 0.5.7 (Ubuntu 14.04 sh) ignores for -c commands (which seems to be how make uses it) so it doesn't do anything.
make -p will also interest you, which prints the values of set variables.
CMake generated Makefiles always support VERBOSE=1
As in:
mkdir build
cd build
cmake ..
make VERBOSE=1
Dedicated question at: Using CMake with GNU Make: How can I see the exact commands?
Library makefiles, which are generated by autotools (the ./configure you have to issue) often have a verbose option, so basically, using make VERBOSE=1 or make V=1 should give you the full commands.
But this depends on how the makefile was generated.
The -d option might help, but it will give you an extremely long output.
Since GNU Make version 4.0, the --trace argument is a nice way to tell what and why a makefile do, outputing lines like:
makefile:8: target 'foo.o' does not exist
or
makefile:12: update target 'foo' due to: bar
Use make V=1
Other suggestions here:
make VERBOSE=1 - did not work at least from my trials.
make -n - displays only logical operation, not command line being executed. E.g. CC source.cpp
make --debug=j - works as well, but might also enable multi threaded building, causing extra output.
I like to use:
make --debug=j
https://linux.die.net/man/1/make
--debug[=FLAGS]
Print debugging information in addition to normal processing. If the FLAGS are omitted, then the behavior is the same as if -d was specified. FLAGS may be a for all debugging output (same as using -d), b for basic debugging, v for more verbose basic debugging, i for showing implicit rules, j for details on invocation of commands, and m for debugging while remaking makefiles.
Depending on your automake version, you can also use this:
make AM_DEFAULT_VERBOSITY=1
Reference: AM_DEFAULT_VERBOSITY
Note: I added this answer since V=1 did not work for me.
In case you want to see all commands (including the compiled ones) of the default target run:
make --always-make --dry-run
make -Bn
show commands executed the next run of make:
make --dry-run
make -n
You are free to choose a target other than the default in this example.
GNU make gives me a strange error message, which I do not understand.
gao#L8470-130213 ~
$ make
echo Test
C:\Program: C:\Program: is a directory
make: *** [test] Error 126
This is what I thought of verifying:
gao#L8470-130213 ~
$ less makefile
test:
echo Test
gao#L8470-130213 ~
$ which make
/c/Programx86/GnuWin32/bin/make
gao#L8470-130213 ~
$ /c/Progra~2/GnuWin32/bin/make.exe test
echo Test
C:\Program: C:\Program: is a directory
make: *** [test] Error 126
gao#L8470-130213 ~
$ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-pc-mingw32
It feels like some other program is trying to run at the end, and that its path includes some spaces. In that case, what program could it be, and how can I prevent it from running?
I have seen this thread and tried to disable my antivirus, which did not help.
I have also looked into permissions, but I am not sure if makefile needs execution rights. I can't seem to be able to change that anyway (running in bash on windows. makefile is not read-only when I check in explorer):
gao#L8470-130213 ~
$ ls -l makefile
-rw-r--r-- 1 gao Administ 21 Apr 15 14:53 makefile
gao#L8470-130213 ~
$ chmod +x makefile
gao#L8470-130213 ~
$ ls -l makefile
-rw-r--r-- 1 gao Administ 21 Apr 15 14:53 makefile
What is going on with make, what can I do?
It's not "some other program" that's trying to run, it's the echo command. Make prints the command to be run, echo test, but you never see the output (test) so that means it failed trying to find the echo program. Unfortunately I'm not very familiar with the vagaries of running GNU make on Windows: there are lots of different options. One possibility would be to get a newer version of GNU make; 3.81 is very old. 3.82 is now available and might work better for you.
Good info you added above about your environment re: using bash; that wasn't clear from the original question and on Windows there are many different ways to do things. You're using the mingw version of make; that version (as I understand it) does NOT use bash as the shell to run commands in: it's supposed to be used with native Windows environments which do not, certainly, have bash available. I believe that the version of make you have is invoking commands directly, and/or using command.com. Certainly not a UNIX shell like bash.
If you want to use bash you should set the SHELL make variable to the path of your bash.exe program. If you're using a Cygwin environment you can use the GNU make that comes with Cygwin which behaves more like a traditional make + shell.
Otherwise you'll need to write your commands using Windows command.com statements.
Again, I don't use Windows so this is mostly hearsay.
PS. The makefile does not need to be executable.
What is going on is that make doesn't like file names or directory names with spaces in them, such as Program Files. Neither do most of the utilities that makefiles typically rely on, such as the shell to execute commands with.
I create a junction from Program Files to ProgramFiles and use the latter whenever I encounter cases like this.
Do you think it's possible to compile ssh using the Intel compiler? I don't really know where to start and there's not much info on google, so I thought I'd ask the community.
I really want to take advantage of the compression performance improvements. My idea is to set up an unencrypted ssh tunnel (but with maximum compression) as follows:
ssh -N -g -f -C -o CompressionLevel=9 -o Cipher=none eamorr#172.16.1.218 -L 6999:172.16.1.218:3129
Any advice greatly appreciated,
Build instructions for OpenSSH can be found here: http://unixwiz.net/techtips/openssh.html.
When you do the ./configure steps you'll want to do something like ./configure CC=icc CXX=icpc in order to use the ICC compiler rather than gcc.
If you've done it right then when you subsequently do a make you should see during the build that the compile lines will start with icc ... or icpc ... rather than gcc ... or g++ ....
On AIX, I would run:
ar -X32 -t libdb2.a
and check for output to determine if there is a 32-bit object in the archive. Similarly with -X64 for checking for a 64-bit object. However, what about if I'm on another platform, and need to check the archive to see what it has? Usually I'm on Linux when I need to check, but I could just as easily be on Solaris or HP-UX.
I used to check for shr.o and shr_64.o, since that's what's being compiled, but those are starting to show up in actual messages that are in the archives, and thus the reliability of these have dropped to the point where I'm getting false positives.
If anyone has a pointer, preferably something I can do in perl, that'd be great.
I don't think there is an easy way. If you create two AIX archives, one 32-bit and one 64-bit, as follows:
$ cat a.c
int foo (void) { return 42; }
$ xlc -q32 a.c -c -o a32.o
$ xlc -q64 a.c -c -o a64.o
$ ar -X32 cr a32.a a32.o
$ ar -X64 cr a64.a a64.o
you end up with archives that are not in a readable format by the linux ar:
$ file a32.a a64.a
a32.a: archive (big format)
a64.a: archive (big format)
$ ar t a32.a
ar: a32.a: File format not recognized
$ ar t a64.a
ar: a64.a: File format not recognized
I tried using strings to see if anything obvious was in the archives, but found nothing. Your ony remaining option is to build a binutils package targetting AIX (download binutils, configure with option --target=powerpc-ibm-aix5.3, run make and voilà: you've got a tool called powerpc-ibm-aix5.3-ar somewhere in that build tree).
I'd suggest extract one of the .o files from the .a archive, and then running the file command on it. Example:
$ file fortune/fortune.o
fortune/fortune.o: ELF 32-bit MSB relocatable, SPARC, version 1 (SYSV), not stripped
file isn't standard on every system, but can easily be compiled. Alternatively, there are a couple of perl modules which do the same thing as file.
ar offers the p command which prints the file in question. For example:
$ ar p libcurl.a base64.o > /tmp/base64.o
$ file /tmp/base64.o
base64.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
So... I'm one year late, but I just had the exact same problem. Here is how I solved it, I hope it helps someone:
$ ar t mylib.a
myobj1.o
myobj2.o
myobj3.o
$ mkdir /tmp/mylib
$ cp mylib.a /tmp/mylib
$ cd /tmp/mylib
$ ls
mylib.a
$ ar x mylib.a
$ ls
mylib.a
myobj1.o
myobj2.o
myobj3.o
$ file *
Possible outcomes:
mylib.a: current ar archive
myobj1.o: ELF 64-bit (...)
myobj2.o: ELF 64-bit (...)
myobj3.o: ELF 64-bit (...)
OR
mylib.a: current ar archive
myobj1.o: ELF 32-bit (...)
myobj2.o: ELF 32-bit (...)
myobj3.o: ELF 32-bit (...)
Explanation:
An archive library file is just a collection of ".o" files, when you use the "t" argument of ar you list the contents of the archive and when you use the "x" argument of ar you extract them. Type man ar for further instructions.