I3ISU_Opgave7

Exercise 1 Debugging using gdb
We have chosen to use our application from exercise 5 with shared data. Because it has both threads and synchronization. We start by compiling our program for host: code g++ -O0 -g -o main main.cpp -pthread code

We then open the program with gdb and insert a breakpoint and singlestep through the program: code Reading symbols from /home/stud/Dropbox/Linux/ISU/Exc7/main...done. (gdb) b reader Breakpoint 1 at 0x80485aa: file main.cpp, line 11. (gdb) r Starting program: /home/stud/Dropbox/Linux/ISU/Exc7/main [Thread debugging using libthread_db enabled] [New Thread 0xb7fe7b70 (LWP 11498)] [Switching to Thread 0xb7fe7b70 (LWP 11498)]

Breakpoint 1, reader at main.cpp:11 11         for(int i = 0; i < 10; i++) (gdb) bt Backtrace stopped: Not enough registers or memory available to unwind further (gdb)
 * 1) 0 reader  at main.cpp:11
 * 2) 1 0x00137d31 in start_thread  from /lib/i386-linux-gnu/libpthread.so.0
 * 3) 2 0x0021f46e in clone  from /lib/i386-linux-gnu/libc.so.6

code

We then introduce a segmentation fault with the function badFunc, from the lecture slide: code Breakpoint 1, badFunc at main.cpp:11 11         int* p = 0; (gdb) n 12         *p = 1; (gdb) n

Program received signal SIGSEGV, Segmentation fault. 0x080485b4 in badFunc at main.cpp:12 12         *p = 1; (gdb)

code After introducing the segmentation fault we run the program with gdb and places a breakpoint at badFunc. After that we singlestep through the program and hits the segmentation fault.

Exercise 2 Using ddd
We start by running the program with ddd: code ddd ./main code ddd is an ui for debugging tools such as gdb. And we have configured ddd to use gdb. This means we get the exact same results as with gdb except we now have a more visual overview of the program. We run the program and see the threads and get the segmentation fault, just as with gdb.

Exercise 3 Cross debugging
We have two terminals running. One for host and one for target. We start out by starting gdbserver on target and starting the arm debugger on host:

Target: code Process ./main.target created; pid = 1510 Listening on port 1234 code Host: code ... Reading symbols from /home/stud/Dropbox/Linux/ISU/Exc7/main.target...done.
 * 1) gdbserver localhost:1234 ./main.target
 * 1) arm-angstrom-linux-gnueabi-gdb ./main.target

code

We then set the shared library path and connected to target from host: code (gdb) set solib-absolute-prefix /home/stud/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard Reading symbols from /home/stud/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/lib/ld-linux.so.3...done. Loaded symbols for /home/stud/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/lib/ld-linux.so.3 (gdb) target remote 10.9.8.2:1234 Remote debugging using 10.9.8.2:1234 code We then proceeded as with host debugging except we remembered to use the c command instead of r command. We found the error like we did on host.

Exercise 4 Core dumps
Remember to run the command //ulimit -c unlimited// to enable core dumps. We then run the program and gets a dumped core. We then run the core with gdb and finds the error as before: code ... Core was generated by `./main.target'. Program terminated with signal 11, Segmentation fault.
 * 1) gdb ./main.target core
 * 1) 0 0x000085b8 in badFunc  at main.cpp:12

12         *p = 1; (gdb)

code We can see there is a segmentation fault on line 12 in function badFunc.

Exercise 5 Cross debugging using ddd
When running ddd we used the following command: code ddd --debugger "arm-angstrom-linux-gnueabi-gdb" code We can then proceed as in the other exercises and we get the same results.

Exercise 6 Valgrind & Hellgrind
We run the program with valgrind: code valgrind ./main code When running we get the following output this is the summarys for memory leak and heap: code

12787
HEAP SUMMARY:

12787
in use at exit: 272 bytes in 2 blocks

12787
total heap usage: 2 allocs, 0 frees, 272 bytes allocated

12787
LEAK SUMMARY:

12787
definitely lost: 0 bytes in 0 blocks

12787
indirectly lost: 0 bytes in 0 blocks

12787
possibly lost: 272 bytes in 2 blocks

12787
still reachable: 0 bytes in 0 blocks

12787
suppressed: 0 bytes in 0 blocks

12787
Rerun with --leak-check=full to see details of leaked memory

12787
For counts of detected and suppressed errors, rerun with: -v

12787
ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 13 from 6) code As the summarys show we have 272 bytes in 2 blocks that are possibly lost. Possibly lost means that Valgrind does not know whether it is something we are doing deliberately or it is an error. We also recive the following thread issues code

12787
Thread 2:

12787
Invalid write of size 4

12787
at 0x80485B4: badFunc (main.cpp:12)

12787
by 0x80485C6: reader(void*) (main.cpp:17)

12787
by 0x4049D30: start_thread (pthread_create.c:304)

12787
by 0x413246D: clone (clone.S:130)

12787
Address 0x0 is not stack'd, malloc'd or (recently) free'd

code