I want to use valgrind massif to figure out the heap memory used by 7-Zip. When I run massif on 7-Zip, it produces no output. Here's the command.
valgrind --tool=massif /usr/bin/7z a filename.7z filename
I would expect an output file named massif.out.pid within the current directory but no such output is produced. I should add that, using massif on other compression tools like gzip, bzip2, compress, etc. produces a massif.out.pid file.
I also used valgrind -v and there is no helpful information there either.
Any thoughts on why this doesn't work for 7-Zip?
/usr/bin/7z is a wrapper script.
#! /bin/sh
exec /usr/lib/p7zip/7z "$#"
Try running
valgrind --tool=massif /usr/lib/p7zip/7z a filename.7z filename
instead.
Related
The boost test library supports various logging options, for example: --log_level=all or log_level=test_suite.
And the ctest test driver program has the option --output-on-failure which nicely outputs the messages from boost test.
Is it possible to enable the above output for passed tests too?
It will give a little more than what you're after, but you can add the --verbose flag to ctest and it will show the output of all tests whether they pass or fail.
Although its an old quetion, but could help to answer it.
yes its possible to putput both failed and passed test with -O <file>, --output-log <file>
-O <file>, --output-log <file>
Output to log file.
This option tells CTest to write all its output to a log file.
https://cmake.org/cmake/help/latest/manual/ctest.1.html
I wanted to log both xml and text output results of valgrind memcheck.
I tried this command .
valgrind --tool=memcheck --xml=yes --log-file=TextLog.log --xml-file=XMLFile.log test
but only xml file was written.text file had no data..
No need of using tool option to set it to 'memcheck', since by default valgrind uses 'memcheck' as the tool. Just for your information.
Even there is no issue also, in using tool option.
Try using the below command, to get the logs in both XML file and log file.
valgrind --xml=yes --xml-file=XMLFile.log > Textlog.log 2>&1 test
Is this one you are expecting?
more information can be found in below link,
http://valgrind.org/docs/manual/manual-core.html#manual-core.basicopts
There is no documentation that I can find beyond the oneliner provided by the command-line utility. It says:
-batch force batch I/O
So what's going on here if I pass it a query or multiple queries?
When the sqlite3 shell is run interactively, it shows a startup message and the sqlite> prompt, and (on Windows) tries to converts the input to UTF-8.
If the automatic console detection does not work as intended, it can be overridden with -batch or -interactive.
Is there a way to tail a file by name on Solaris 10?
Equivalent to:
tail --follow=name
Manual for tail on solaris shows no such option. Only -f is included and it looks like it follows a file by descriptor.
According to the GNU tail manual, --follows is the same as -f:
-f, --follow[={name|descriptor}]
output appended data as the file grows;
an absent option argument means 'descriptor'
A -f option is found in the POSIX description of tail. However, the --follows option (which accepts an option value) is not in POSIX. The GNU manual goes on to describe the --follow option where it differs from -f:
With --follow (-f), tail defaults to following the file descriptor,
which means that even if a tail'ed file is renamed, tail will
continue to track its end. This default behavior is not desirable
when you really want to track the actual name of the file, not the
file descriptor (e.g., log rotation). Use --follow=name in that
case. That causes tail to track the named file in a way that
accommodates renaming, removal and creation.
That is, --follow provides for reopening the file if the actual file was renamed. POSIX does not appear to address this use case.
There is no direct equivalent in Solaris's differences from POSIX (compare /usr/bin/tail and /usr/xpg4/bin/tail in manual).
GNU tail is part of the coreutils package. You may already have it installed on Solaris 10, in /opt/sfw/bin/tail. For instance, pkginfo shows it on my Solaris 10 machine as SFWcoreu.
Solaris does not have --follow as you see.
The workaround is redirection:
tail -f inputfile > filewritten_by_tail
Your best bet is to install GNU find either from source or some freeware repository.
If you really want to stick with Solaris 10 bundled find, you'll need to wrap it with a custom monitoring program that will restart it should the target file is renewed.
Works like a charm on solaris 11!
/usr/bin/gtail -F
Is there a tool which given a cgi program, and the arguments (query string, method, file to upload, etc.) would set the correct environment variables, and execute this program (with or without a debugger.
Something like this perl script, only more solid, with a more clear output and input, support for files, etc.
Well, a new open source project was born from this question. I'm copying my answer from here.
If you just want to see your CGI running, you can use my tiny runCGI project.
All you need is to set a yaml file which looks something like this
_exec: /var/cgi-bin/myfile.cgi
method: GET
query_string:
q: s
and then run
./runCGI myyamlfile.yaml
You will see the output on the console's standard output.
You can even debug it with gdb, debug runCGI gdb runCGI, run with the correct parameters (run someyaml.yaml), issue tcatch exec (tcatch catches it only once) and then set breakpoints to your CGI file:
$ g++ a.cc -o a.out
$ cat a.yaml
method: GET
_exec: a.out
$ gdb runCGI
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(gdb) tcatch exec
Catchpoint 1 (exec)
(gdb) run a.yaml
Starting program: /home/elazar/runCGI/runCGI a.yaml
Executing new program: /home/elazar/runCGI/a.out
0x00007fc3a24a6a60 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) tbreak main
Breakpoint 2 at 0x400577: file a.cc, line 2.
(gdb) c
Continuing.
main (argc=1, argv=0x7fff14891408) at a.cc:2
2 int a =0;
(gdb)