ELEC424/COMP424/ELEC553: Mobile & Embedded Systems
Lab 1: Part 3: Making it fail again
The most important step of finding a bug is to reproduce its effect. Difficult bugs are usually those whose effects are hard to reproduce. In this part, you will get a taste of this albeit through an artificial bug.
We have provided a binary library file libtime.a that exposes one function, int gettime(void). This function is supposed to print out the current time (hour: minute: second). We have implanted a crash condition in it so that it occasionally causes any program calling it to crash after the printout. It’s your job to figure out under what conditions the program crashes.
Of course, you need to write a program that calls our gettime(), run it, and see if it crashes. Simply include the header file mytime.h in your source file, and then call it as you wish. A sample program using our function can be found here (yep, that simple!).
To compile and run the sample test prgram:
Remember that we have made it difficult to produce the crash. Like real difficult bugs, the crash happens rarely (so rarely that you may think it won't happen at all); and it happens in a seemingly random way. Therefore, you want to automate the process so that you do not have to spend days before the computer trying manually.
In Part 1, you tried to be a hacker and examined a program using GDB. In Part 2, you should try to be a detective going after a serial killer: gather all data from each kill scene and see how dots are connected.
Writing the Report
In your report, please include in a detailed description of the crash condition you determined (be specific). Also, explain how you discovered it as well as any insights you had during the debugging/analysis process.