0% found this document useful (0 votes)
19 views

Session 3

The document discusses various debugging tools and techniques for finding and fixing bugs in programs. It covers iterative debugging using breakpoints, printing and logging statements, and postmortem debugging using core dumps. Interactive debugging allows sending requests to a debugger while a program is running, while postmortem debugging analyzes core dumps generated after a program crashes. The GNU Debugger (GDB) allows setting breakpoints and stepping through code line-by-line. Compiling with debugging symbols enabled (-g flag) provides more detailed information for debugging. Backtraces show the call stack to identify the location of errors.

Uploaded by

assala benmalek
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
19 views

Session 3

The document discusses various debugging tools and techniques for finding and fixing bugs in programs. It covers iterative debugging using breakpoints, printing and logging statements, and postmortem debugging using core dumps. Interactive debugging allows sending requests to a debugger while a program is running, while postmortem debugging analyzes core dumps generated after a program crashes. The GNU Debugger (GDB) allows setting breakpoints and stepping through code line-by-line. Compiling with debugging symbols enabled (-g flag) provides more detailed information for debugging. Backtraces show the call stack to identify the location of errors.

Uploaded by

assala benmalek
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 3

Programs debugging:

debugging tools:
iterative debugging

debgging techniques :
break points

debugging cycle:

developement (testing) *deployement*

maximum bugs should be detected in the testing phase!

debugging types:

=> printing , logging: print the flow of the execution


=> itterative debugging *tool
=> postmotem debugging *tool

difference bwtween printting and logging : Logging the messages are written in log
files ! we can open these
files and analyse what's written in logging files !!! not effective because it
needs to change the code and recompile not recommended!

debugging tools are recommended !

break points:
watch points: ask the program to stop at a certain condition !
back trace
core dump

GDB debugger!
_________________________________________________________________________

use the debugging tools:

the difference between interactive debgging and postmorterm debgging :

interactive debugging : send request to debugger and the debugger responds ! but
this debuggig tool is not always possible !
why? => program can crush no running program to debug !
=> when the program is running wihout a debugger ! (on a machine or...)
=> no pemission to access !

postmortemm debugging using coredemp binary files that are generated by corrupted
programs that have bugs and have the most important info about the execution
of the progam and can be analized offline and can be done on a different
computer !
coredump are binary files geneated by the OS!

SIG SEGV error !


segmentation fault error ! look for that

call stack :

a stack that contains all the called functions !

________________________________________________________________________________
Use the GDB the GNU debugger :

debugging program should know the location of the error !


break points need line number

configuation for the debugging :

inclde additional info in the binary code !


how to get the information of the program loop location ,vaiables names......?
---> include the info within the binary ! how?

commands on linux: cd , ls , pwd , ll , :wq to exit the .cfile ! , mv,mkdir


we can't debugg the excecute file because it contains only the bina code !

we need the debug symboles to debug the pogram like : the name of the fnction ,
location ...

add -g
gcc -g fact.c -o fact.exe // add the -g when compiling to add the information to
the binay !

instead of: gcc fact.c -o fact.exe

we candebug without the bina smboesbut we cannot get the visuale info !

add the bea point :

(gdb)break fa
gdb./fact debug.exe
(gdb)beak 5
gdb) run

in this case the debgger run until line 5 !

(gdb) s
(gdb) pint

comileagain

gcc -g fact.c -o fact.exe


./fact.exe
continue and stepoverr

continue => run to the next line


step over => run until the next break point and ou can get back !

______________________________________________________________________________

make the diffenece eteen the two types of the binary files :

file fact_debug.exe the file command can be detect the debug info => with debug
info !

back trace :

how to print the function call stack of our program !

when executing ./fact.exe


and get
segmentation fault it means we are trying to access some memory area that is fault

os sends the segmentation violation signal to the process and the pocess ends the
execution diectly!

crush =! bugs

in cushes onl we get the core dumped file!

./prog2.exe
gdb prog2.exe
run

to now what is the last einstrunction executed before the crush we do back trace

(gdb)bt command

we can intall the version of standard librar with the standard symboles!

You might also like