I'm trying to use check unit testing framework for my C application. But I can't use the debugger (gdb) with it because of two points:
first, check use some complex macros (START_TEST and END_TEST) and the debugger has trouble to put a breakpoint in my code between these two macros (in fact, I can put a software breakpoint but It is never seen by gdb)
second, check define some sort of exceptions by redefining behavior of interruption. Hence, when I try to put a hardware breakpoint, the test failed and exit because check consider the hardware breakpoint as a failure of my test.
Does anyone has already met this problem and has a solution?
Look at the no-fork mode:
Check normally forks to create a separate address space. This allows a signal or early exit to be caught and reported, rather than taking down the entire test program, and is normally very useful. However, when you are trying to debug why the segmentation fault or other program error occurred, forking makes it difficult to use debugging tools.
Actually, you CAN use fork-mode too.
gdb has two interesting options related to fork behaviour:
- detach-on-fork (set this to false)
- follow-on-fork (either parent or child; I always take child)
This will make gdb follow the child process.
When the child process has ended, you have to manually switch back to the parent process by using the inferior command.
I read this and he suggests a very simple solution:
gdb > set environment CK_FORK=no
that worked for me. I could then set a breakpoint in functions the test cases call (that is, the functions under test), and it broke at the right place.
Try TAP (Test Anything Protocol) … it's a lot easier to implement, ship and debug. It's also very easy to make it valgrind-aware and tends to play nicer with gdb.
Related
Im trying to find if there is a way to hide/avoid printing variable values in case of core dump. I see when there is a core dump, when traversed through gdb, we are able to find the value of the variables which is expected, but in need of a way where this doesnt happen. I came across this particular link in my quest for my answer. But I still see the values being printed.
(gdb) p data
$1 = (void *) 0x615000
(gdb)
Im trying to find if there is a way to hide/avoid printing variable values in case of core dump.
The usual way to achieve that is install a signal handler for all fatal signals.
In the handler, you would zero out all secret variables, then reset the handler to SIG_DFL and re-raise the signal.
say a secret code being saved in a variable and I wouldnt want that to be let out when gdb
Certainly madvise(...MADV_DONTDUMP) in your linked answer will not achieve that.
You can use some anti-debugging techniques, such as fork() followed by ptrace attach, with the child and parent using a complicated handshake and the child only decoding secrets when it knows that it's being traced by a trusted parent.
Beware: you will have very hard time debugging your program when it goes wrong, and a sufficiently motivated attacker in control of the machine will defeat your protections anyway.
Your efforts are likely better spent elsewhere.
I am debugging an application to fix a segmentation fault that I suspect to be caused by a race condition.
I'd like to put some print statements in the code, but I know for experience that adding calls to printf is not recommended since this could change the behavior of the threads and in some case hide the bug.
Looking at other options, I have seen that with gdb it is possible to use break points to print something and then automatically continue the execution:
break foo
commands
silent
printf "Called foo: x is %d\n",x
cont
end
Is this any better then putting a printf in my code?
I know that gdb has a also Tracepoints but they only work with gdbserver and this is an additional level of complication that I would prefer to avoid at the moment.
Additional information: the application is written in C and it runs on Linux.
Is this any better then putting a printf in my code?
No, it's much worse. Every breakpoint that is hit in GDB triggers the following chain of events:
context switch from running thread to GDB
GDB stops all other threads (assuming default all-stop mode)
GDB evaluates breakpoint commands
GDB resumes all threads (this is itself a complicated multi-step process, which I would not go into here).
This is at least an order of magnitude more expensive and disruptive than a simple printf call, and is very likely to hide whatever race you were trying to debug.
The bottom line is that GDB is in general completely unsuitable for debugging data races.
I second the ThreadSanitizer recommendation by Christopher Ian Stern.
The only problem with this bug is that I am doing the debug on a production machine where I cannot install other SW.
First, ThreadSanitizer instruments your existing program. It has a runtime library, but that could be statically linked into your binary. There is nothing that you need to install on your production machine.
Second, ThreadSanitizer detects data races even when they do not cause visible behavior changes. It may well turn out that you don't need to run on your production machine at all: simply running your tests (you do have tests, right?) on your development machine may prove to be sufficient.
Since you are on Linux, I would recomend ThreadSanitizer. That is using a recent version of gcc or clang and passing -fsanitize=thread to the build. This isn't a printf repacment but should tell you explicitly about any race conditions in your code. Even after you solve this problem if you are working with multithreaded code, you will want to have this tool available. Alternately, or in addition, I have had good results with Valgrind's http://valgrind.org Data Race Detector, but I would start with ThreadSanitizer.
I am currently writing an application in C, targetting BSD and Linux systems with a hope to being generall portable. This program a runtime dependency, in this case mplayer.
As it stands I am using execlp() to start mplayer. I am checking the error code of the execlp call and I am testing for EACCESS, so I know when I attempt to run mplayer if it exists or not.
Because of the way my program works, mplayer is a required dependency but may not be used for some time after my program starts. As a user experience it is poor for the program to have been running for some time before failing due to mplayer being missing. So I would like to test for mplayer existing as my program starts up. Probably delivering an error message if mplayer is not available.
Now I understand there is a race condition here so my current handling of an EACCESS error will have to stay. We could find a situation where a user starts my program running, then uninstalls mplayer. This is accepted.
My initial thought was to call execlp() early on in execution and however this results in mplayer visibly starting. To be honest I'd prefer not to be starting mplayer, just testing if I "could" start it (eg. does a file exist called mplayer somewhere in my path and is it executable).
A second thought was then to run those precise steps, looking through the path and testing if the matching file is executable. I've not yet coded this for two reasons. The first reason, to be sure execlp is finding the same thing I have found I would have to pass the discovered pathname to execlp, bypassing the builtin PATH searching mechanism. The other reason is simply I feel I'm missing an obvious trick.
Is there a function I should be using to do the search for an executable? Or do I really need to just get on and code it the long way.
Some systems (FreeBSD, Linux) support a which command that searches the user's path for a given command.
I suppose that begs the question in a sense... if your code might run on a variety of systems, you might feel the need to do which which just to determine if which is available. ;-) If that's a problem you might still have to consider building that functionality into your program, but the code could still be a helpful starting point.
with a hope to being generally portable
To POSIX platforms, I suppose? execlp is far from generally available.
There's no portable way to check for a command's availability except trying to execute it. What you could do is copy the path finding logic from BSD execlp (the userland part), or BSD's which command.
There is no certain way in ANSI C. You may try fopen() and check return code.
Try to use stat call (man 2 stat), it exists on Linux, but I'm not sure about BSD.
I'm doing a project that makes unix system calls. To be specific, my project heavily relies of calls to getcontext(), makecontext(), swapcontext() and setcontext(). I tried to debug my code using gdb. I stepped into the code line by line and examined the control but once a call to swapcontext() is made, it doesn't step into the code anymore. Instead, debugging almost stops there and the rest of the program is run automatically instead of line by line. I guess gdb does not go into context calls? Is there any way to get around this? Is there a debugger that i can use for this?
Thanks
setcontext and swapcontext calls change the program's stack, and gdb gets confused. I do not know whether some other debugger can handle it nicely.
gdb steps through one thread and calls this the current thread. Other threads will run as you are doing this. If you set a breakpoint that gets hit in a thread other than the current thread then gdb will change the current thread to that thread. Stepping is now relative to the new current thread.
Stepping with gdb over calls of swapcontext() with 'step' or 'next' does not work because not only the stackpointer changes but also the call returns to a different code line (which is the desired effect of swapcontext()). As gdb puts a breakpoint in the next code line which will not be executed until another swapcontext() returns to this place the execution will not break.
You need to foresee the line to which swapcontext() will return and set a breakpoint there. For a new (unused) context this will be the line you specified as entry function. For used contexts it will probably one of the lines after a swapcontext() there...
You can repeatedly use GDB's stepi command to first step into and then step through the swapcontext() function. You must step several dozen times, including a few steps over kernel system calls—I presume to save the floating point state?—and you'll eventually come out in the user thread you're swapping to. It's a tad time-consuming, but it works.
As much as you may not like this answer, the best bet is to step through your code in small chunks by hand. Threaded programs don't play very well with debuggers like GDB and Valgrind (at least in my experience) and most bugs can be determined by a careful step-by-step manual analysis of the code.
I have a program which produces a fatal error with a testcase, and I can locate the problem by reading the log and the stack trace of the fatal - it turns out that there is a read operation upon a null pointer.
But when I try to attach gdb to it and set a breakpoint around the suspicious code, the null pointer just cannot be observed! The program works smoothly without any error.
This is a single-process, single-thread program, I didn't experience this kind of thing before. Can anyone give me some comments? Thanks.
Appended: I also tried to call pause() syscall before the fatal-trigger code, and expected to make the program sleep before fatal point and then attach the gdb on it on-the-fly, sadly, no fatal occurred.
It's only guesswork without looking at the code, but debuggers sometimes do this:
They initialize certain stuff for you
The timing of the operations is changed
I don't have a quote on GDB, but I do have one on valgrind (granted the two do wildly different things..)
My program crashes normally, but doesn't under Valgrind, or vice versa. What's happening?
When a program runs under Valgrind,
its environment is slightly different
to when it runs natively. For example,
the memory layout is different, and
the way that threads are scheduled is
different.
Same would go for GDB.
Most of the time this doesn't make any
difference, but it can, particularly
if your program is buggy.
So the true problem is likely in your program.
There can be several things happening.. The timing of the application can be changed, so if it's a multi threaded application it is possible that you for example first set the ready flag and then copy the data into the buffer, without debugger attached the other thread might access the buffer before the buffer is filled or some pointer is set.
It's could also be possible that some application has anti-debug functionality. Maybe the piece of code is never touched when running inside a debugger.
One way to analyze it is with a core dump. Which you can create by ulimit -c unlimited then start the application and when the core is dumped you could load it into gdb with gdb ./application ./core You can find a useful write-up here: http://www.ffnn.nl/pages/articles/linux/gdb-gnu-debugger-intro.php
If it is an invalid read on a pointer, then unpredictable behaviour is possible. Since you already know what is causing the fault, you should get rid of it asap. In general, expect the unexpected when dealing with faulty pointer operations.