How to interpret breakpoints in GDB?

Question

My code

#include <stdlib.h>
#include <stdio.h>

int main()
{
int i=0;
int j=0;
size_t count=0;
float numbers[20][100];
float velocity[21][101];
char *line = NULL;

FILE *myFile;
myFile = fopen("vel.txt", "r");

    if (myFile == NULL)
    {
        printf("Error Reading File\n");
        exit (0);
    }

while(i < 20 && getline(&line, &count, myFile)!=-1) {
int len = 0, pos = 0;
    j = 0;
    while(j < 100 && 1 == sscanf(line + pos, "%f%n", &numbers[i][j++], &len))
        pos += len;
    i++;
}
free(line); 
fclose(myFile);

for( i = 0; i < 21; i++ )
    for( j = 0; j < 101; j++ )
    {
       if( i= 1 && j == 1 )
       {
       velocity[i][j]=numbers[i][j];  
       }
       else if ( i= 1 && j == 101 )
       {
       velocity[i][j]=numbers[i][j];   
       }  
       else if ( i=1 && j >= 2 && j <= 100)
       {
       velocity[i][j]=(numbers[i][j-1]+numbers[i][j])/2;       
       }   
       else if(i >= 2 && i <= 20 && j == 1)
       {
       velocity[i][j]=(numbers[i-1][j]+numbers[i][j])/2;
       }
       else if(i >= 2 && i <= 20 && j == 101)
       {
       velocity[i][j]=(numbers[i-1][j]+numbers[i][j])/2;
       }
       else if(i >= 2 && i <= 20 && j >= 2 && j <= 100) //means i goes from 2,20 j goes from 2,100
       {
       velocity[i][j]=(numbers[i-1][j]+numbers[i][j]+numbers[i][j]+numbers[i][j])/4;
       }     
       else if( i= 21 && j == 1 )
       {
       velocity[i][j]=numbers[i][j];  
       }  
       else if ( i=21 && j >= 2 && j <= 100)
       {
       velocity[i][j]=(numbers[i][j-1]+numbers[i][j])/2;       
       }   
       else 
       {
       velocity[i][j]=numbers[i][j];   
       }
    }

return 0;
}

I can compile this with gcc but then exe is runnin gforever.So something is wrong.I try to debug like this

Breakpoint 1, main () at a1.c:11
11  char *line = NULL;
(gdb) c
Continuing.

Breakpoint 2, main () at a1.c:35
35         if( i= 1 && j == 1 )
(gdb) c
Continuing.

Breakpoint 2, main () at a1.c:35
35         if( i= 1 && j == 1 )
(gdb) c
Continuing.

Breakpoint 2, main () at a1.c:35
35         if( i= 1 && j == 1 )
(gdb) n
39         else if ( i= 1 && j == 101 )

But I am total beginner,what does this breakpoint tells me?

Answer 1

Here's your problem:

if( i= 1 && j == 1 )

You wind up resetting i to 1 each time through the loop. Change that to

if ( i == 1 && j == 1 )

One common trick to avoid this is to put the constant expression on the left-hand side:

if ( 1 == i && 1 == j )

That way, if you forget one of the = signs, the compiler will yell at you (a constant expression cannot be the target of an assignment). Note that I do not personally endorse this practice - I only mention it as one possible option. IMO, the right thing to do is to turn up the warning levels on your compiler.

Edit

Regarding debugging with gdb, all a breakpoint does is stop execution at a particular instruction; it doesn't actually tell you anything. However, it gives you a chance to examine the state of your program.

To look at the contents of a particular variable, use the p command:

(gdb) p i
(gdb) p j

To examine memory at a specific address, use x:

(gdb) x/b &i

examines a single byte starting that the address of variable i:

(gdb) x/32b &i

examines the 32 bytes starting at the address of the variable i.

You can also check the state of your stack using bt. Here's a handy cheat sheet of gdb commands.

Answer 2

Turn on warnings.

Most C compilers do not have warnings on by default. This is unfortunate because they provide a lot of information for debugging.

Command line compilers usually use -Wall, but that often does not turn on all warnings. Yes, this is silly. If you're using clang you can use -Weverything to get everything. gcc has -Wextra in addition to -Wall. Most have -pedantic to ensure you're following the standard.

Fix all the warnings, even if they seem silly. Your code has a bunch that are easily fixed.

Use valgrind.

After you've fixed the warnings, you can find memory problems using a program like Valgrind. This is usually as simple as valgrind ./your_executable. This will show you all the places you walked out of allocated memory, a very common problem in C.

Interpreting the results can be challenging. Learn C The Hard Way has some information about how to do that.

Break your code up into functions and test them.

This basic technique applies to any language: write small, testable functions, and test them. By ensuring each small piece works, you only need to worry about the code gluing them together.

In your code, for example, that giant for loop that works with velocity and numbers should be in its own function. Then it can be tested separately from the code which takes input to build `numbers.

You don't need anything fancy to do the testing, assert() works fine to start with. Here's an example from another question.