Getting a Segmentation fault

[Nextstopearth]

This is the beginning of an avl tree project. I've never heard of a segmentation fault before now, but after some reading I guess is has something to do with read/writing is a specific point in memory that the OS doesn't allow? Well I'd really appreciate if someone could point out my error in this part of the program, I'm sure it's probably something simple. I believe the offending line is the first line of the insert function.

#include <stdio.h>

	typedef struct node{
		struct node * left;
		struct node * right;
		int value;
	} NODE;

	typedef struct tree{
		NODE * root;
	} TREE;

/*Function declarations*/
	void insert(NODE * node, NODE * root);
	int getheight(NODE * node);

int main(void){
	TREE tree;
	NODE rt;
	rt.value = 3;
	rt.left = NULL;
	rt.right = NULL;
	NODE nd1;

	tree.root = &rt;
	tree.root->value = 3;
	/*declare new node and put in tree*/
	nd1.value = 1;
	insert(&nd1, tree.root);


	return 0;
}

void insert(NODE * node, NODE * root){
	if ( node->value > root->value && root->right == NULL){ //<----this ???

			root->right = node;
	}	
	else{
		insert(node, root->right);
	}

		  
	if ( node->value < root->value && root->left == NULL ){
		root->right = node;
	}
	else{
		insert(node, root->left);
	}	
}

[vart]

your if/else is wrong

if ( node->value > root->value && root->right == NULL){ //<----this ???

			root->right = node;
	}	
	else{
/* here you go if node->value <= root->value || root->right != NULL */
		insert(node, root->right);
	}

[PING]

You need to make nd1.right and nd1.left equal to NULL.

[MK27]

I've never heard of a segmentation fault before now, but after some reading I guess is has something to do with read/writing is a specific point in memory that the OS doesn't allow?

Segmentation faults are very common and I'm sure you are familiar with them tho you may not know them by name. It is caused by memory corruption but not because the OS "doesn't allow" something -- rather the opposite, it had to allow a read/write and by allowing it, the memory of the process has become corrupted in a critical way. For example, spot the programming error here:

#include <stdio.h>
#include <string.h>

int main() {
	char *ptr;
	strcpy(ptr,"hello world");
	printf("%s\n",ptr);
	return 0;
}

Now, this may not cause a seg fault -- it may actually run. But for me, here, at least it does not work, and causes a "segmentation fault".

Whether or not your OS has been telling you that's what happened is another issue.

[iMalc]

Segmentation faults are very common and I'm sure you are familiar with them tho you may not know them by name. It is caused by memory corruption but not because the OS "doesn't allow" something

Er not in a virtual memory environment...
It is caused by the app trying to read or write to a memory location that it is not allowed to. For example if you try and write to something at NULL, then this doesn't corrupt your program, the memory around NULL isn't even mapped to any physical address so the write causes a page fault which the OS determines is an invalid page request and generates a segmentation fault. It doesn't actually perform the write so there is nothing to corrupt.
Of course this doesn't mean that you cannot have corrupted memory to say get that NULL pointer to begin with, but it's not directly related to currupted memory, nor does corruption happen at the time of a segmentation fault. It is simply an invalid memory request.
Access Violation is another name for it.

[MK27]

Access Violation is another name for it.

I did wonder about this, and hoped some smart person such as yourself would come along and correct me. So it is a slap from the OS, and not a chain reaction type event (thanks iMalc).

Anyway, I would guess a seg fault is still the number one runtime error for most programmers.

[vart]

Anyway, I would guess a seg fault is still the number one runtime error for most programmers.

I do not really get what you mean by that.

If you mean that crash bugs have top-most priority - then yes, because they make very bad impression when happend on the customer use.

If you mean - they are majority of the bugs encountered - then no, not at all... Less than 5% (maybe even a lot less - I need to check my bug traking system on work) of found bugs in the projects I'm working with are about crashes...

[MK27]

I do not really get what you mean by that.

I meant No.1 in terms of noticability!

Anyway, my Original Point has to do with the fact that the Original Poster seemed to be getting red-herring'd by the issue (eg, in believing that a seg fault was something truly unusual that had never happened to me before). On my system, the OS always says "segmentation fault", but I have inferred from other people that this is not necessarily the case everywhere, you may just have a window disappear or something inexplicable but ungood happen.

I think you would have to be some a real freak of nature to get beyond a few hours of trying to learn C programming without experiencing an actual "segmentation fault", but maybe I'm wrong...

ps. you are scaring me again with that last message vart. please stop.

[iMalc]

I think you would have to be some a real freak of nature to get beyond a few hours of trying to learn C programming without experiencing an actual "segmentation fault", but maybe I'm wrong...

I'd certainly agree there!

[vart]

ps. you are scaring me again with that last message vart. please stop.

What's up, doc?