Thread: Pointer error in linked list

I know there is a very simple error in this that I just can't see. I am trying to load a sentence into a stack list, and while my function works, the pointers don't connect.

Code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
typedef struct link {
	char word[30];
	struct link *nextPtr;
} Link, *LinkPtr;
 
void pushWord(LinkPtr curPtr, char inWord[30]);
void printList(LinkPtr curPtr);
 
int main(void) {
 
	char buffer[500] = "The quick brown fox jumps over the lazy dog.";
	LinkPtr list0 = malloc(sizeof(Link));
 
	char* token = strtok(buffer, " ");
	strcpy(list0->word, token);
	list0->nextPtr = NULL;
 
	while (token != NULL) {
		token = strtok(NULL, " ");
		pushWord(list0, token);
	}
 
	printList(list0);
}
 
void pushWord(LinkPtr curPtr, char inWord[30]) {
	while (curPtr->nextPtr != NULL) {
		curPtr = curPtr->nextPtr;
	}
	curPtr->nextPtr = malloc(sizeof(Link));
	curPtr = curPtr->nextPtr;
	strcpy(curPtr->word, inWord);
	curPtr->nextPtr = NULL;
}
 
void printList(LinkPtr curPtr) {
	while (curPtr != NULL) {
		printf(" %s", curPtr->word);
		curPtr = curPtr->nextPtr;
	}
}

as curPtr changes word and nextPtr members, the original list remains unchanged.

As far as I can see I find it weird that you call strtok() and then pass token as a parameter, how do you know token is not NULL?

As a matter of fact it is:

Code:

#1  0x0000000000400a98 in pushWord (curPtr=0x6031c0, inWord=0x0) at main.c:43

Thanks for that. I was sure it was a pointer error. Is your code-tagged portion from your debugger? Would you mind explaining it to me? I assume that curPtr=0x6031c0 and inWord=0x0 are the values stored in the variable/array and that 0x0 is equivalent to NULL which is how you knew that a null value was inside the inWord array.

I think the best I know how to do in my IDE is to go into debug mode and step through it until it tells me:

Exception thrown at 0x0FCC0E13 (ucrtbased.dll) in 10 Reversing a sentence.exe: 0xC0000005: Access violation reading location 0x00000000.

If there is a handler for this exception, the program may be safely continued.

It then brings up the assembly code in strcat.asm and points to a line within what might be a label. This label reads "main_loop_entrance". There is some mov code and the comment "read 4 bytes." I am not planning on learning assembly though.

Maybe once I learn error handling this kind of thing will be easier for me.

Originally Posted by jack jordan

Thanks for that. I was sure it was a pointer error. Is your code-tagged portion from your debugger? Would you mind explaining it to me? I assume that curPtr=0x6031c0 and inWord=0x0 are the values stored in the variable/array and that 0x0 is equivalent to NULL which is how you knew that a null value was inside the inWord array.

I think the best I know how to do in my IDE is to go into debug mode and step through it until it tells me:

It then brings up the assembly code in strcat.asm and points to a line within what might be a label. This label reads "main_loop_entrance". There is some mov code and the comment "read 4 bytes." I am not planning on learning assembly though.

Maybe once I learn error handling this kind of thing will be easier for me.

I debug with gdb by passing the -g flag when compiling.
GDB: The GNU Project Debugger
Debugging with GDB: Top

When running the program with the debugger, if you have a SIGSEGV you'll encounter something like:

Code:

(gdb) run
...
Program received signal SIGSEGV, Segmentation fault.                                   
0x0000000000400886 in main () at main.c:37                                             
37          printf("%i\n", *a);  
(gdb) backtrace full
#0  0x0000000000400886 in main () at main.c:37                                         
        reg = 233 '\351'                                                               
        cant_sat = 30                                                                  
        id = GNSS_CZD                                                                  
        a = 0x0

If you were to have functions, you may have different frames, you can go through each of then with the frame command, and the print command can also give you an idea of what the current variables are in that frame.

I don't really know that much else, maybe someone else could give you more details.

In visual IDEs, like MSVC and Code::Blocks there is a window for the call stack. As long as you've compiled for debugging, the call stack will probably be more informative of where the error happened.

For example, what you quoted jack:

Exception thrown at 0x0FCC0E13 (ucrtbased.dll) in 10 Reversing a sentence.exe: 0xC0000005: Access violation reading location 0x00000000.

If there is a handler for this exception, the program may be safely continued.

The error is obviously not in the ucrtbased.dll because that is a system library (the C library). When you look at the call stack though, you should see what code called the other code you don't know above it. You just keep looking up until you find files and code that you recognize, and that is probably where the problem is. Then you'll have to look around, look at variables in that call, to find a reasonable explanation.

In the while loop, where you're reading the words...

Code:

        token = strtok(NULL, " ");
        pushWord(list0, token);

After the final word is tokenised (token != NULL) the while loop is executed again where strtok will return NULL and you're then trying to push NULL onto your stack (consequently pushWord() calls strcpy with NULL as an argument for the "from" parameter). I would swap the order of those two statements and adjust the preliminary code accordingly