The Art of Debugging With Gdb Ddd and Eclipse

I of the most common questions nosotros hear on the ns-3 developers list is a variation on the following theme: I wrote my program, but when I run information technology I get a cherry line that ends with "terminated with signal SIGSEGV". Please tell me what I did wrong.

The complete output from waf will await something similar,

          ./waf --run hs          Waf: Entering directory `/domicile/craigdo/repos/ns-three-allinone-dev/ns-3-dev/build'          Waf: Leaving directory `/home/craigdo/repos/ns-iii-allinone-dev/ns-iii-dev/build'          'build' finished successfully (0.881s)          Command ['/domicile/craigdo/repos/ns-3-allinone-dev/ns-iii-dev/build/debug/scratch/hs']   terminated with point SIGSEGV. Run information technology under a debugger to go more information   (./waf --run <programme> --command-template="gdb --args %due south <args>").        

In this HOWTO, we describe what this ways and how yous tin can go about finding your trouble.

Contents

  • i HOWTO understand and find cause of terminated with signal errors
    • 1.1 Reproduce the Trouble
    • 1.two What the Trouble Means
    • 1.3 Let's Reproduce I of Those
    • 1.4 Finding and Fixing the Problem
    • 1.5 More Errors
    • 1.vi What Next
  • 2 Determination

HOWTO understand and notice cause of terminated with point errors

The zeroth thing to understand about debugging is that i of the least productive things you lot can practise is post a pile of your code on a developers list and inquire why information technology doesn't work. Developers are very busy people who won't take a lot of spare time to do your work for yous. Try and figure it out on your ain. You are doing the correct affair by reading this page!

The beginning thing to understand is that debugging anything is an art and skill that you need to larn. Some jokers have observed that programming tin be defined as the human action of introducing bugs. This is not too far from the truth (which is why information technology is funny). Since you volition exist programming in the ns-3 environmnent, you are going to have to develop debugging skills, whether you like information technology or not, in society to remove the bugs you create. This HOWTO is only going to scratch the surface of the bailiwick of debugging and hopefully provide you with a management and a few hints regarding how to outset. You are going to have to figure most of this out on your own, though. Don't worry, information technology gets easier.

Information technology volition exist much easier on you if yous learn from the experience of others. At that place are many books available that will help you learn the details of this huge subject. If you go to Amazon.com and search for "debugging" in their books department, you will find over 2,000 results. A couple of books that have been recommended on ns-developers are

  • Agans, "Debugging"
  • Matloff and Salzman, "The Art of Debugging with GDB, DDD, and Eclipse"

Reproduce the Problem

If you lot accept read a good volume on debugging, you will know that the first footstep in finding whatever trouble is to figure out how to reproduce it. In this case, we demand to produce it, and so let's have the simplest ns-3 example and create a reproducible problem.

The hello-simulator.cc example, you may call back, just prints the text "Hello Simulator" on your console using the ns-3 logging system. It is simple enough that we tin reproduce it hither:

          #include "ns3/core-module.h"  NS_LOG_COMPONENT_DEFINE ("HelloSimulator");  using namespace ns3;      int   main (int argc, char *argv[])  {    NS_LOG_UNCOND ("Howdy Simulator");  }        

Go alee and copy the instance into the scratch directory. The following assumes that you are in the base directory of an ns-three distribution (the directory where RELEASE, VERSION and src are found).

          cp examples/tutorial/howdy-simulator.cc scratch/hs.cc        

Now pull up the file y'all just created (scratch/hs.cc) in you favorite programmer's editor and add a line then that the main funtion looks like this:

          int   main (int argc, char *argv[])  {    NS_LOG_UNCOND ("Howdy Simulator");    return 1;  }        

Go alee and build and run the new plan:

          ./waf  ./waf --run hs        

Yous should see something that looks like:

          Waf: Inbound directory `/your/directory/path/ns-three-allinone-dev/ns-3-dev/build'          Waf: Leaving directory `/your/directory/path/ns-3-allinone-dev/ns-3-dev/build'          'build' finished successfully (0.872s)          Hello Simulator          Control ['/your/directory/path/ns-iii-allinone-dev/ns-3-dev/build/debug/scratch/hs'] exited with code 1        

Yous should now take a reproducible issues, since if y'all echo the waf run command, your program exits with code 1 every time.

What the Trouble Means

The short answer is that the program did not return a zero every bit its leave or return code. Waf reports this back in ruby since information technology ordinarily means that the program has failed in some way. This render code tin either come up from the return value from your main part, or it can be supplied by the operating arrangement or run-time system if your program does not complete for some reason.

In general, strictly positive render codes betoken a program that completed "normally" (that is, the main function returned some value) only detected some error. In the code to a higher place, the hs programme completed ordinarily, only returned the value 1. In existent-world programs, this would indicate an fault condition that you as a user could await up in the hs documentation and interpret. In this case, waf does not know what the render value of one means, so it just reports that value.

Negative render codes typically betoken that the program has failed in some mode such that it cannot complete. In Unix and Linux, these codes are usually the negative of a then-called Indicate. You tin can find a listing of signals in /usr/include/asm/signal.h if you are interested. The kickoff few are:

          #ascertain SIGHUP   ane  #define SIGINT   2  #define SIGQUIT  3  #ascertain SIGILL   4  #define SIGTRAP  5  #define SIGABRT  vi  #define SIGIOT   half dozen  #ascertain SIGBUS   7  #define SIGFPE   8  #ascertain SIGKILL  9  #define SIGUSR1  10  #define SIGSEGV  11  #ascertain SIGUSR2  12  #define SIGPIPE  13  #define SIGALRM  xiv  #define SIGTERM  15        

Since these negative error codes are well known, waf tin interpret a return value that is really a negative integer into a string value. A common case is if excuting your programme causes the operating system to intervene and return an exit code of -eleven. The root crusade is something called a SIGSEGV point since its divers value is eleven, which is the negative of -11. Waf converts the -11 to the cord "indicate SIGSEGV" and prints this every bit its output.

Google is your friend. If you search for sigsegv, you volition find a prissy Wikipedia entry: http://en.wikipedia.org/wiki/SIGSEGV which and so points you to another Wikipedia page: http://en.wikipedia.org/wiki/Segmentation_fault

On that page, yous will find a reasonable definition of a segmentation violation:

          A segmentation mistake (frequently shortened to segfault) or access violation is a   particular error condition that tin occur during the performance of reckoner   software. A partition error occurs when a program attempts to admission a   memory location that it is non immune to access, or attempts to admission a  retention location in a fashion that is non allowed (for instance, attempting to   write to a read-only location, or to overwrite part of the operating   system)        

This is what is happening when you run your program and you see the dreaded ruddy bulletin from waf:

          Command ['/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build/debug/scratch/hs']   terminated with point SIGSEGV. Run it under a debugger to get more information (./waf --run <plan>   --command-template="gdb --args %s <args>").        

Let'due south Reproduce I of Those

Pull up the file you created (scratch/hs.cc) in you favorite programmer's editor and change that line you added so that the principal funtion looks similar this:

          int   main (int argc, char *argv[])  {    NS_LOG_UNCOND ("Hello Simulator");    *(char *)0 = 0;  }        

If you lot build and run, you should at present see that waf highlights the fact that your programme now crashes with a partitioning mistake by displaying the infamous crimson line:

          Waf: Entering directory `/your/directory/path/ns-3-allinone-dev/ns-iii-dev/build'          Waf: Leaving directory `/your/directory/path/ns-3-allinone-dev/ns-3-dev/build'          'build' finished successfully (0.872s)          Hi Simulator          Control ['/dwelling/craigdo/repos/ns-iii-allinone-dev/ns-3-dev/build/debug/scratch/hs']   terminated with signal SIGSEGV. Run information technology under a debugger to get more information (./waf --run <program>   --command-template="gdb --args %south <args>").        

What yous have washed by adding the line,

          *(char *)0 = 0;        

is to endeavour to write a goose egg byte to address zero of your system. In every system that I can call up of, address nix is located in a reserved system page that almost likely includes important things like reset vectors which users must not be allowed to alter. Therefore, this admission must be illegal for several reasons; and your operating organisation detects this attempt to modify the page and summarily stops your program. This is called "a crash."

So, when your program exits with a SIGSEGV, information technology has done something that the operating arrangement considers as bad with respect to accessing memory. The ruby-red line with the error code from waf is only telling yous what has happened. Your adjacent job is to figure out what you did that the operating organization doesn't similar.

Finding and Fixing the Problem

Since there are literally an infinte number of ways you can innovate a sectionalization violation into your code, there is no style I can tell you how to set up your code. What I can practice is to explain how to run your programme in a debugger so you lot tin can see the bespeak at which the operating system decided your program has gone bad. There are many debuggers, and you will probably come to know and love gdb for its power and ubiquity. Permit'southward start with something minor, though. For beginners, a graphical debugger is probably the mode to go, and insight is fairly intuitive to apply. It turns out that insight is actually a graphical wrapper for gdb, and then you can eventually go to the more powerful gdb features as you larn more; so this isn't a completely pointless exercise :-)

If your arrangement does not come with insight, you tin can install the package simply by using either

          sudo yum install insight        

or

          sudo apt-get install insight        

There are two basic ways to run a program under a debugger in ns-3. You can run the plan using a so-called command-template as is suggested by waf in its mistake message:

          ./waf --run hs --control-template="insight %s"        

or you lot can enter a vanquish and change into the appropriate directory and run the degugger directly

          ./waf shell  cd build/debug/scratch  insight hs        

If you choose insight, in either case, you lot will end up with a new window -- an insight source window. If you lot choose gdb (every bit waf suggests) you will in upwards with a control line debugger. I'll assume you lot went with insight from hither on.

If yous click the piffling "running man" icon on the toolbar correct under the "File" menu item (run into the image beneath), a breakpoint (google is still your friend) volition automatically be set up for you at the kickoff of the main function and your program volition be started and run. Execution of your program volition exist stopped at the first source line in main which is the NS_LOG_UNCOND that prints "Hi Simulator". The fact that the program has stopped is indicated to you by the green background at the source line. You should exist seeing a window that looks similar the following;

Insight.png

To the right of the "running man" are some parenthesis icons that control execution of your programme. Most of them have arrows that end upwardly pointing downward (stepping "down" into functions). 1 of them has a reddish pointer pointing to the right. This is the "go on" push. If you press this button, your plan will "proceed" running until it exits, hits another breakponit, or does something evil.

Go ahead and press the button. You lot will come across a warning popup window appear that tells y'all that insight has "received point SIGSEGV, Sectionalisation fault". You expected something similar that, right? If you dismiss the popup, insight will bear witness you at which source line the programme stopped by coloring its groundwork greenish. In this case, the offending line is,

          *(char *)0 = 0;        

which caused a partition mistake by attempting to write to a system folio (exterior the valid address infinite of your program).

More Errors

From the list of signals above, yous may take already figured out that there are a number of errors that will cause the operating organization to intervene and terminate your program. Let'southward illustrate some other mutual case. Pull up the file you created (scratch/hs.cc) in yous favorite programmer's editor and change that line you added so that the primary funtion looks like this:

          int   main (int argc, char *argv[])  {    NS_LOG_UNCOND ("Hi Simulator");    int i0 = 0, i1 = ane;    NS_LOG_UNCOND (i1 / i0);  }        

If you lot build and run, you should now see that waf highlights the fact that your program crashes with a different fault:

          Waf: Entering directory `/your/directory/path/ns-3-allinone-dev/ns-3-dev/build'          Waf: Leaving directory `/your/directory/path/ns-3-allinone-dev/ns-three-dev/build'          'build' finished successfully (0.872s)          Hullo Simulator          Control ['/home/craigdo/repos/ns-3-allinone-dev/ns-iii-dev/build/debug/scratch/hs']  terminated with betoken SIGFPE. Run it under a debugger to become more information (./waf --run <program>   --control-template="gdb --args %s <args>").        

What you have done by calculation the lines,

          int i0 = 0, i1 = 1;    NS_LOG_UNCOND (i1 / i0);        

is to crusade a partitioning-by-zero error in your programme. The name SIGFPE indicates a Floating Bespeak Exception (FPE) even though there are no floating point numbers in sight. Information technology turns out that SIGFPE is used for general arithmetic exceptions. Once more, google is your friend if you want to figure out exactly what these signals mean. Wikipedia provides a folio defended to SIGFPE (http://en.wikipedia.org/wiki/SIGFPE).

So, when your program exits with a SIGFPE, it has done something that the operating organisation considers equally bad from an arithmentic point of view. The red line with the error code from waf is simply telling y'all what has happened. Your job volition be to effigy out what the system didn't like (from looking at the offending source line and the variables involved).

What Next

Obviously, this HOWTO is not a place to provide a manual for the insight debugger, nor is it a place for general debugging references. Yous tin can attempt to push button forward on your own by reading the insight documentation and trying to effigy out debugging on your ain. If you lot are new enough to this debugging thing to accept learned anything in this HOWTO, I strongly recommend that you selection up one of the books on debugging techniques and start working through some of their examples. It volition near likely save y'all a lot of stress.

Conclusion

As mentioned above, debugging is both an art and a skill and you can spend the residuum of your life mastering it. Many of the states learned the hard way by having many, many bugs principal us. You lot can choose that manner, the hard way, but nosotros who accept been down that road think it will pay off if y'all take a small suspension at this betoken and do some reading or ask a colleague with real experience in this expanse for some assist and guidance.

Good luck and happy debugging!


Craigdo 02:34, 24 April 2010 (UTC)

louckswhissent.blogspot.com

Source: https://www.nsnam.org/wiki/HOWTO_understand_and_find_cause_of_terminated_with_signal_errors

Belum ada Komentar untuk "The Art of Debugging With Gdb Ddd and Eclipse"

Posting Komentar

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel