Segmentation fault, cannot find problem

[navitude]

I have a file with a single string of 150 characters. The string consists of combinations that either refers to room dimensions, door placement or item placement for a rogue game.

I have successfuly opened the file, read the string, tokenized the string by spaces, stored each token into a 2 dimensional string called **storage, and passed over **storage to a function without errors.

Below is the code I am using in the new function to break up the first string in **stored, which is 10X16, and print out the room borders using ncurse. The problem is that I am getting a segmentation fault, but I have no idea where it is coming form. Also, is there a better way to do this?

int counter = 0;
  
  char * token = malloc(sizeof(char *) * 151);
  
  int x = 0;
  int y = 0;
  
  if(strcmp(storage[counter], "1") == 0 || strcmp(storage[counter], "2") == 0 || strcmp(storage[counter], "3") == 0 || strcmp(storage[counter], "4") == 0 || strcmp(storage[counter], "5") == 0 || strcmp(storage[counter], "6") == 0 || strcmp(storage[counter], "7") == 0 || strcmp(storage[counter], "8") == 0 || strcmp(storage[counter], "9") == 0)
  {
    token = strtok(storage[counter], "X");
    
    x = atol(token);
    
    token = strtok(NULL, "X");
    
    y = atol(token);
    
    /* blank screen refresh */
    clear();
    move(0,0);
    refresh();
    
    for(counter = 0; counter != x; counter++)
    {
      mvaddch(0, counter, '=');
      mvaddch(y, counter, '=');
    }
    
    for(counter = 1; counter != y; counter++)
    {
      mvaddch(counter, 0, '=');
      mvaddch(counter, x, '=');
    }
    
    move(0,0);
    refresh();
  }

Thanks for your time and help ahead of time.

[Salem]

> The problem is that I am getting a segmentation fault, but I have no idea where it is coming form.
1. Compile with debug
Eg
gcc -g prog.c

2. Load it in the debugger
Eg
gdb ./a.out

3. Run it
Eg
(gdb) run

4. Wait for the inevitable crash.

5. Use the following commands
bt - to display the stack trace (tells you where you are - no more guessing)
frame n - to jump between stack frames of interest. The most interesting is probably the innermost function you've written.
print x - to print x (or any other variable name or expression)

[grumpy]

The only possibility I can see is that the first strtok() call returns a NULL pointer. Which will happen if the code in the if() is executed, since all the strcmp() calls mean that storage[counter] does not contain an 'X'. The atol() calls will therefore exhibit undefined behaviour. One possible symptom of undefined behaviour is a program crash - either immediately, or in some other code.


I'm not convinced that the code you have shown is the only cause of problems though. The nature of undefined behaviour (of which segmentation faults are just one of many possible symptoms) is that the cause may be ANY code executed AT OR BEFORE the point where the symptom is detected.

Sadly, that means your belief that you "have successfuly opened the file, read the string, tokenized the string by spaces, stored each token into a 2 dimensional string called **storage, and passed over **storage to a function without errors" may be incorrect. Any of those things you describe may be the cause, except that the symptom was not immediately visible.

What you need to do is create a SMALL but COMPLETE sample of code that someone else can compile and build, in order to recreate your symptoms. In the process of finding that sample, you might find the problem yourself. It is entirely possible that removing some of the code that you believe is working could eliminate the problem. If that is the case, it indicates that code is a contributor to the symptoms, despite your belief it is running correctly.



That code is also leaking memory. strtok(a,b) returns a pointer to character within a, or it returns a NULL pointer. Either way, using the malloc() call to initialise token before calling strtok() means the malloc'ed memory is leaked (it is allocated, but your program loses track of it, so cannot deallocate it).

[navitude]

>
frame n - to jump between stack frames of interest. The most interesting is probably the innermost function you've written.
print x - to print x (or any other variable name or expression)

thanks,

Thanks! I found the error for the fault is, line 8 in the sample code I gave above.

I think I see a couple of problems. First is a logic error, I am trying to take the whole string and compare it to a single character, which should give me a value as they are not equal thus skipping the printing.

Second is that the way I am calling the variable is incorrect in some way thus I am calling something I don't want to and that is leading to the fault.

And thats where I am stuck...?

[navitude]

The only possibility I can see is that the first strtok() call returns a NULL pointer. Which will happen if the code in the if() is executed, since all the strcmp() calls mean that storage[counter] does not contain an 'X'. The atol() calls will therefore exhibit undefined behaviour. One possible symptom of undefined behaviour is a program crash - either immediately, or in some other code.

******** Edit ***********

Solved: Your right about the strtok(). It will create an error. But the seg.. fault that I'm currently dealing with does come from the way I calling the storage variable. I am now moving the tokenizing from my main() to the function, then tokenizing and printing out the image one part at a time without using a 2d string.

I would like to figure out whats going wrong with the way I'm callaing storage but I need to get this done. Thanks.

*******Old ********


Thanks for your insight on strtok(). It clarifies a little bit. I'm thinking of trying to use a character by character comparison insted of strtok(), which should likely not encounter the problem.

As to your comments about errors somewhere else in the code. I've coded each section, up to this point, in sections with test inputs and output checks. Everything has checked out and precessed the way I wanted it to, so I'm 98% sure that its this last 3% that contains the problem.

Thanks