C++ Debugging


A comprehensive discussion of debugging issues can be seen at this Wisconsin Univerity Site. The web pages at our local site here will present the specific error message, the relevent portions of the C++ code, and the solution to the problem. Generic debug tips are presented where possible.

This first error illustrates how you can get shot down before you even manage to take off!!

hercules[67]% CC lab2.cpp -LANG:std -o lab2


CC ERROR:  file does not exist:  lab2.cpp
hercules[72]%
The compiler is saying that there is no file called lab2.cpp - but isn't that our C++ program? Well, actually no, if we looked further back in time, we would see that when the file was created it was not give a .cpp extension. Remember that a C++ program must have an extension of cpp on a Unix system. The solution here is to rename the file accordingly. i.e. mv lab2.ext lab2.cpp

Debugging Tip: Be objective when you read error messages. Don't get so caught up in the syntax of the programming language that you forget to check the environment. e.g. Maybe the file is named incorrectly, or maybe it is in a subdirectory.


Here is another simple error, but one that results in a pile of error messages.

hercules[67]% CC lab2.cpp -Lang:std -o lab2


cc-1035 CC: WARNING File = /usr/include/CC/iostream, Line = 18
  #error directive:  This header file requires the -LANG:std option

  #error This header file requires the -LANG:std option
   ^
cc-1132 CC: ERROR File = /usr/include/CC/ios, Line = 346
  The class "std::char_traits" has no member "off_type".
    typedef typename _Traits::off_type off_type;
          detected during instantiation of class
                "std::basic_ios>" at line 43


. . .   // a lot more ugly error message appeared here!!


cc-1239 CC: ERROR File = lab2.cpp, Line = 101
  "cout" is ambiguous.
        cout << endl;
        ^
10 errors detected in the compilation of "lab2.cpp".
hercules[68]%

Well that certainly was ugly! It was even uglier in the orginal version - most of the errors were not printed here. The trick to debugging a mess like this is to start with the first error message and see what you can do to fix that problem.

Debugging Tip: Sometimes will get a great long list of compile errors. Many times if you clear up the first few errors, the rest will disappear when you compile again. Don't even bother looking at the later errors.

So let's look back at that first error message and see what it's complaining about.
cc-1035 CC: WARNING File = /usr/include/CC/iostream, Line = 18 #error directive: This header file requires the -LANG:std option #error This header file requires the -LANG:std option

But we entered the "LANG" thing on the compile line - or did we? Again, let's look back:
hercules[67]% CC lab2.cpp -Lang:std -o lab2
Do you see the problem?
The compiler wants LANG but we've given it Lang. We were warned that Unix is very case sensitive. This is an example of that case sensitivity.


This next example shows a warning message rather than an error message.

hercules[99]% CC 2Darray.cpp -LANG:std -o 2Darray


cc-1174 CC: WARNING File = 2Darray.cpp, Line = 14
  The variable "Mums" was declared but never referenced.

      int Mums[3][5];

Debugging Tip: Don't ignore Warning messages - they have a way of coming back to bite you when you least expect it.

In this example, the programmer meant to use the variable Nums rather than Mums. It was a simple typing error, but had the programmer carried on to use the "Nums" variable in the rest of the program, there would be fatal errors.


Here's an error you are likely to encounter at some point.

hercules[131]% CC addit.cpp -LANG:std -o addit

cc-1129 CC: ERROR File = addit.cpp, Line = 18
  A left brace ("{") is expected at this point.
  void main()
  ^

cc-1220 CC: ERROR File = addit.cpp, Line = 63
  The function "InitArray" has already been defined.

  void InitArray(int p_Array[][C_size])
       ^
2 errors detected in the compilation of "addit.cpp".
hercules[132]%

Looks nasty doesn't it? Going back to a previous tip, let's focus on the first error message in the list. The compiler is complaining about line 18. If you go into vi and enter the command :18 you will be moved to line 18. This would show you that the void main() statement is located on line 18. Nothing wrong with that line - perhaps the problem is with the line before that. Here are lines 16-19 from that program:

void InitArray( int [][C_size] ) // function prototype

void main()
{

Hmmm, is there something wrong with that function prototype statement? If it's a C++ statement (and it is - or should be), then it should end with a semi-colon. So the solution here is simply to add the semi-colon. The rest of the errors will disappear.
void InitArray( int [][C_size] ) ; // function prototype

Debugging Tip: When an error message is reported on a specific line, and you cannot see a problem with that line, look to the line just before that one. Remember that to go to a specific line in vi, enter :n (where n is the line number).

Pointers Running Wild!! You need to be careful when you use pointers, because if you are not careful, a pointer could take on a memory address that is outside the bounds of your program space.

If that happens you could see the very cryptic message:

Segmentation fault - core dump.
This is a really ugly way of punting you and your program out of computer memory. Unix guru's might have some hope of decyphering the core file which is supposed to be a dump of the contents of memory (called core way back when the earth was cooling. Yes, C is that old.)

Normal people deal with the core file more simply.

        rm   core
does the trick quite nicely. That can be a truly big file, so you don't want it hanging around taking up your disk space. On some systems though, core files are automatically deleted after one week.

But what about the problem that caused the dump in the first place?! Well, if you like, you can try the following commands to see if you can get more information about the problem with your program.

   dbx a.out core        (or whatever)
     where
     quit
However, if you're using pointers in your program, it's likely that one of them took on a bad value. Go back to your source code and look for statements that change pointer values. Remember that when you are in vi, you can search for a particular string (such as the name of a pointer) by entering: /search_string/

This page has been accessed     times.
Last modified: Sunday, 25-Mar-2012 17:42:57 CST
Copyright 2000 Department of Computer Science, University of Regina.


 CS Dept Home Page

Teaching Material