Do i need to use valgrind on each program file with which ".so" is made.. or is there any we can run valgrind directly on ".so" library. please provide steps for later.
Not directly. Library does not have an entry point where to start executing it, and valgrind only checks code that is actually executing.
Still, if you want to test a library with valgrind, there is a simple way. Just write a test program, which uses the library in the way that tests the parts and features of library you want tested. Then valgrind that.
It is probably better to write several small test programs to test different features and use patterns, instead if one big one which tries to test everything in one execution (easier to isolate any problem valgrind finds, faster to run).
Valgrind watches upon code that being executed. Shared library is never executed unless some program uses them. If some code never executed, valgrind will never notice it.
Related
Assume I want to understand a larger project by just stepping through the code with a debugger. Is it possible to just jump in at an arbitrary point (given I define the correct variables)? How do I debug libraries that don't have a main?
To debug code in a library, write a little application (that has a main()) that calls the functions in the library you need to debug. Then debug that application and step into the library calls it makes.
As for just "jumping into an arbitrary location" - well, you can instruct the debugger to move the instruction pointer to wherever you please, but that's usually not what you want, because you'd be missing a lot of state that previous parts of the program will have created. Usually what you want to do is set a breakpoint in the function you are interested in and then just run the program normally until you hit the breakpoint.
The best way would be to run the application as it is and set a breakpoint whenever you want to look. The thing is that the program might do lot of initialization and other stuff, that you wouldn't be able to figure out.
Another approach would be to look out for unit tests. They are like small programs itself targeting just specific parts of the program.
I need to allocate an exact set of shared library dependencies of a binary program. I'm working on linux and the project is written in my C++. Thus, I need a recursive ldd-like functionality in C++. How can I do it?
To quote Han Solo, "I got a bad feeling about this". Setting up a chroot for a child process from within a C++ program sounds like some architectural misconception / screwup further up the line. Sorry, no ready-made C++ solution that springs to mind. You could, of course, run ltrace / strace / recursive-ldd and parse their output...
...but generally speaking, the idea is to set up the chroot environment statically (i.e. before any processes are started), not dynamically. With a dynamic approach, an attacker could fool the main process into believing it should give the child process things it shouldn't have in the chroot. That defeats the whole purpose.
Tools for statically setting up chroot environments for a given executable are plenty, tools for doing so dynamically I couldn't find any. This is a hint in itself.
In the meantime I've found the following:
linux/gcc: ldd functionality from inside a C/C++ program
where the accepted answer suggests to use:
setenv("LD_TRACE_LOADED_OBJECTS", "1", 1);
FILE *ldd = popen("/lib/libz.so");
I tried it out and worked both from bash and from C++ (ofc in this case I think of an equivalent version). However if I ran either versions for a SUID binary (what I actually have) then I got exit code 5 (i guess permission problems).
Then I traced what ldd exactly does and the following seems fine (at least in command line):
LD_TRACE_LOADED_OBJECTS=1 /lib64/ld-linux-x86-64.so.2 binary_name
The (dummy) question is: what is the equivalent implementation of this in C++?
I'm having a complete program, but now, I want it to be able to be updated. So I would like to change the "code" in the executable by the new code without having to recompile it.
Is it possible? If yes, how can I do, I coding in C++ in Qt Creator.
Thanks for any advise/clue
C++ can't do this. With QT, you could have a javascript implementation of the code you want changed and update that.
I did exactly what Jon told me : simply replace the old exe by the new one
While you can't technically do this in C++ without recompiling, if you don't want to rewrite in another programming language, you could write a small helper program that (while the original program is not running) recompiles the first program.
If you really wanted to do this (it's not hard at all) I'd look into GNU g++.
If you're using Windows, you'll probably want MinGW (which I believe comes with g++ installed). Both are free/open source and fall under the GNU GPL (something you need to look at if you are planning on selling your program. However, you're free to give it away)
Basically you could run your program, call another program before closing, and have that program act as a script to call g++ to re-compile your code. I've done this before, but for faster debugging rather than actually releasing a program that works that way.
Not sure this answers your needs, but did you look into the ClickOnce platform? Although the code still gets recompiled on your server the client executable gets updated via ClickOnce.
I'm facing a problem that is so mysterious, that I don't even know how to formulate this question... I cannot even post any piece of code.
I develop a big project on my own, started from scratch. It's nearly release time, but I can't get rid of some annoying error. My program writes an output file from time to time and during that I get either:
std::string out_of_range error
std::string length_error
just lots of nonsense on output
Worth noting that those errors appear very rarely and can never be reproduced, even with the same input. Memcheck shows no memory violation, even on runs where errors were previously noted. Cppcheck has no complains as well. I use STL and pthreads intensively, but without the latter one errors also happen.
I tried both newest g++ and icpc. I am running on some version of Ubuntu, but I don't believe that's the reason.
I would appreciate any help from you, guys, on how to tackle such problems.
Thanks in advance.
Enable coredumps (ulimit -c or setrlimit()), get a core and start gdb'ing. Or, if you can, make a setup where you always run under gdb, so that when the error eventually happen you have some information available.
The symptoms hint at a memory corruption.
If I had to guess, I'd say that something is corrupting the internal state of the std::string object that you're writing out. Does the string object live on the stack? Have you eliminated stack smashing as a possible cause (that wouldn't be detectable by valgrind)?
I would also suggest running your executable under a debugger, set up in such a way that it would trigger a breakpoint whenever the problem happens. This would allow you to examine the state of your process at that point, which might be helpful in figuring out what's going on.
gdb and valgrind are very useful tools for debugging errors like this. valgrind is especially powerful for identifying memory access problems and memory leaks.
I encountered strange optimization bugs in gcc (like a ++i being assembled to i++ in rare circumstances). You could try declaring some critical variables volatile but if valgrind doesn't find anything, chances are low. And of course it's like shooting in the dark...
If you can at least detect that something is wrong in a certain run from inside the program, like detecting nonsensical output, you could then call an empty "gotNonsense()" function that you can break into with gdb.
If you cannot determine where exactly in the code does your program crash, one way to find that place would be using a debug output. Debug output is good way of debugging bugs that cannot be reproduced, because you will get more information about the bug the next time it happens, without the need to actively reproduce it. I recommend using some logging lib for that, boost provides one, for example.
You are using STL intensively, so you can try to run your program with libstdc++ in debug mode. It will do extra checks on iterators, containers and algorithms. To use the libstdc++ debug mode, compile your application with the compiler flag -D_GLIBCXX_DEBUG
I was wondering if its possible / anyone knows any tools out there to compare the execution of two related programs (for example, assignments on a class) to see how similar they are. For example, not to compare the names of functions, but how they use syscalls. One silly case of this would be testing if a C string is printed as (see example below) in more than one case one separate program.
printf("%s",str)
Or as
for (i=0;i<len;i++) printf("%c",str[i]);
I haven´t put much thought into this, but i would imagine that strace / ltrace (maybe even oprofile) would be a good starting point. Particularly, this is for UNIX C / C++ programs.
Thanks.
If you have access to the source code of the two programs, you may build a graph of the functions (each function is a node, and there is an edge from A to B if A calls B()), and compute some graph similarity metrics. This will catch a source code copy made by renaming and reorganizing.
An initial idea would be to use ltrace and strace to log the calls and then use diff on the logs. This would obviously only cover the library an system calls. If you need a more fine granular logging, the oprofile might help.
If you have access to the source code you could instrument your code by compiling it with profiling information and then parse the gcov output after the runs. A pure static source code analysis may be sufficient if your code is not taking different routes depending on external data/state.
I think you can do this kind of thing using valgrind.
A finer-grained version (and depending on what is the access to the program source and what you exactly want in terms of comparison) would be to use kprobes.
Kernel Dynamic Probes (Kprobes) provides a lightweight interface for kernel modules to implant probes and register corresponding probe handlers. A probe is an automated breakpoint that is implanted dynamically in executing (kernel-space) modules without the need to modify their underlying source. Probes are intended to be used as an ad hoc service aid where minimal disruption to the system is required. They are particularly advocated in production environments where the use of interactive debuggers is undesirable. Kprobes also has substantial applicability in test and development environments. During test, faults may be injected or simulated by the probing module. In development, debugging code (for example a printk) may be easily inserted without having to recompile to module under test.