Friday, August 15, 2014

Debugging with GDB - Lets decypher Segmentation Fault

I want to be a philanthropist. Hold on!  Are you looking for any link to get money? Get out of my website if you have wrongly landed here in search of money. I am sure Google (Search engine is not the key word any more) does a good job in listing search results. 

I only offer information in netglutton, after all information is wealth. I recently gathered more information about a tool i use almost every day in my Software Engineer role. a magic three letter tool "GDB - GNU Debugging".

Process crash or Core singles out as "Critical" defect among tons of defects in any software system. It is so severe that both test engineer and developer have hard time in resolving process crash. As a software test engineer i have encountered 100s of Process Crash scenarios. 

Why it happens?
Simply, unhandled exception. Yes, Process crash happens due to unhandled exceptions like Null Pointer, Memory error, EOF etc in code. As a test engineer i have not only seen simple way to trigger a crash but also a most difficult ones. 

DO NOT TRY THIS: 
If you have root access, find a non-restartable process (ps -ef) and do "kill -9 or -11".

"Breaking Point" is very critical issues in code. I really dont want to get into the reason for Crash/Cores. A C/C++ developer must know about GNU Debugging (GDB). Software test engineer should also know about collecting core file, attaching to GDB and finding BT (BackTrace short form).

Unhandled exception OR Null pointer OR Segmentation Fault in process leads to process restart. Process failure leads to core file. Back trace using GDB helps to find breaking function call /memory location/ value. 

With above contextual information, go through following help links for more information about How to GDB?



No comments:

Post a Comment

Thanks for your comment. I will moderate your comment as soon as i get a chance.