BACK-IN-TIME DEBUGGER INTRODUCTION PRINCIPLE OF WORK PROBLEM It is well known that significant effort in the process of software developing is focused. - презентация

1 BACK-IN-TIME DEBUGGER INTRODUCTION PRINCIPLE OF WORK PROBLEM It is well known that significant effort in the process of software developing is focused on debugging, that is searching and fixing errors in the program. The main tool used for this purpose is a debugger. The debugger makes it possible to trace the program execution. However, just to trace the program execution is often not sufficient. The situation may arise, when the point in the program where the error had been produced is far apart from the point where it is revealed and something went wrong. In such cases, the programmer has to restart anew the program being debugged and to concentrate on the variable which made everything bad. And of course, programmer has to reproduce all actions the program made before, otherwise error may not to repeat during the second execution. Surely, it takes a lot of time and effort. The solution to this problem could be a debugger capable of rolling the program after the crash, several steps back. It would make possible debugging from that very place and concentrating on the variable in question without restarting the program. The aim of my work is to create such a debugger. An idea of creating a back-in-time debugger is not a new one. At the moment there already exist some debuggers capable of tracing back the program execution. For example, there are back-in-time debuggers for Java, C#, J#, Ocaml. However, all these debuggers require the program to be compiled in special byte codes, which are further interpreted by a virtual machine. Using a virtual machine gives some advantages if debugger wants to save the state of the debugged program. But these debuggers are not able to accept any arbitrary machine code and start operating with it. In my work, the task was set to create a debugger which works in general-purpose environment. It is rather important for C\C++ programs which are traditionally compiled into machine code. PRACTICAL USE PROGRAM Back-In-Time Debugger is a general-purpose debugger for Linux. It has all standard debugger features and it can restore previous state of the program being debugged. BIT debugger based on a open-source debugger, GDB. It allows debugging programs written in almost any languages, which can be compiled into the Linux native code, including C and C++. BIT Debugger has the following specific features: Restoring the program state, which was saved earlier by special command. (store-ps, restore-ps) Rolling the program several lines back. (go-back) Rolling back the program to the moment, when required function was called (restore-list) Storing a program state: BIT Debugger ParentChild BIT Debugger Parent Child BIT Debugger Restoring a program state: BIT Debugger ParentChild 2 PID = 6000 Program code … BIT Debugger 3 fork() 1 System call fork(): Storing many backups: PID = 6000 call fork call wait … PID = 6001 call fork call wait … PID = 6002 call fork call wait … BIT Debugger PID = 6003 Program code BIT Debugger Parent Program code … The idea is to insert system call fork() in the program executable code, to make a copy of the debugged program process and to save it as a program state (program memory and registers). temp.c Source code Saved program state #1 (line 1) Saved program state #2 (line 5) This state must be restored (line 3) Source code Currently executed line (line 6) Go back command: PID = 6000 call fork call wait … PID = 6001 call fork call wait … PID = 6002 Executed code … Go-back 3 Program code … Program code … Program code … PID = 6000 Program code PID = 6001 Program code PID = 6000 call fork call wait … PID = 6001 Program code PID = 6001 Program code PID = 6000 Program code PID = 6001 Program code PID = 6000 call fork call wait … PID = 6001 call fork call wait … PID = 6000 call fork call wait … PID = 6000 call fork call wait … Program code … Program code … Program code … Program code … Program code … Program code … Program code … Program code … SUMMARY As the Back-In-Time Debugger can keep the number of saved program states by deleting some of them, there is no problem with debugging big programs. Of course only hundred backups for big program is not sufficient for deep analysis of its actions, but in most cases heuristic deleting of program states can keep the most important backups. At least it is enough for fixing the bug. Surely, speed of execution decreases, when we saving program states. Thats the price for opportunity of tracing back the program execution, and this price is less than for searching of the source of the error for a week. Anyway, practical use will show is it true or not. You can find the project BIT Debugger on SourceForge.net. During the research, the opportunity of creating Back-In-Time Debugger for general-purpose environment was shown. BIT Debugger is ready to its usage with C and C++ programs. The most likely situation, in which back-in-time features could save much time, is when the error appears rarely and only with some conditions which user can do. Standard debuggers can only restart anew the program and lose all actions the user made before. It is very difficult to fix such bugs with a standard debugger. By using BIT Debugger, programmer can trace the program execution and understand which user actions made everything bad. Of course, there are many possibilities to improve back-in-time tools. For example, it would be great to view the history of changes of a variable and to load the program state at which this variable changed into strange value. However, just rolling back the program to the moment when required function was called is enough for most situations. Heuristic deleting of backups: Program states PID = 6001 Program code PID = 6000 Program code PID = 6000 Program code