[Beginner]Seg Fault

[the4bidn]

Hello,

My code pasted below is receiving random segmentation faults. I am not sure I took the right approach for a dynamic sized buffer of Triangle objects(3 Vector3f(3 floats)). Any idea's would be greatly appreciated.

The fault happens at the first write after entering the loop but only happens in glx_base code off Nehe's OGL site. This class works flawless all day long in the console.

int cMesh::BuildMesh(cMCNK *pMCNK)
{
	sTriangle *thisTri = NULL;
	sObject *thisObj = NULL;
	sMCNK_Block MCNK = pMCNK->GetMCNK_Block();
	char *buffer = NULL;
	buffer = new char[sizeof(sTriangle) * 256];
	memset(buffer, '\0', sizeof(sTriangle) * 256);
	thisTri = (sTriangle*)buffer[0];
	thisObj = new sObject;a
	memset(thisObj, '\0', sizeof(sObject));
	thisObj->Triangle = thisTri;
	thisObj->numTriangles = 256;
	thisObj->pNext = NULL;
	mesh->Object = thisObj;
	std::cout << mesh->Object->numTriangles;
	int OffsetX = (MCNK.MCNK.position.X);
	int OffsetY = (MCNK.MCNK.position.Z);
	int OffsetZ = (MCNK.MCNK.position.Y);
	
	for(int y = 0; y < 8; y++)
	{
		for(int x = 0; x < 0; x++)
		{
			
			//First Vertex: Pos 1
			thisTri->Vertex[0].X = ((OffsetX)+((x * 3.703703704)));
			thisTri->Vertex[0].Y = ((OffsetY)+pMCNK->GetNoLod(x,y));
			thisTri->Vertex[0].Z = ((OffsetZ)+((y * 3.703703704)));	

			//Second Vertex: Pos 2
			thisTri->Vertex[1].X = ((OffsetX)+(((x + 1) * 3.703703704)));
			thisTri->Vertex[1].Y = ((OffsetY)+pMCNK->GetNoLod((x + 1), y));
			thisTri->Vertex[1].Z = ((OffsetZ)+((y * 3.703703704)));

			//Third Vertex: Pos 10
			thisTri->Vertex[2].X = ((OffsetX)+(((x + 0.5) * 3.703703704)));
			thisTri->Vertex[2].Y = ((OffsetY)+pMCNK->GetLod(x, y));
			thisTri->Vertex[2].Z = ((OffsetZ)+(((y + 0.5) * 3.703703704)));	
			thisTri = thisTri + sizeof(thisTri);

			//First Vertex: Pos 2
			thisTri->Vertex[0].X = ((OffsetX)+(((x + 1) * 3.703703704)));
			thisTri->Vertex[0].Y = ((OffsetY)+pMCNK->GetNoLod((x + 1), y));
			thisTri->Vertex[0].Z = ((OffsetZ)+((y * 3.703703704)));	

			//Second Vertex: Pos 19
			thisTri->Vertex[1].X = ((OffsetX)+(((x + 1) * 3.703703704)));
			thisTri->Vertex[1].Y = ((OffsetY)+pMCNK->GetNoLod((x+1), (y+1)));
			thisTri->Vertex[1].Z = ((OffsetZ)+(((y + 1) * 3.703703704)));

			//Third Vertex: Pos 10
			thisTri->Vertex[2].X = ((OffsetX)+(((x + 0.5) * 3.703703704)));
			thisTri->Vertex[2].Y = ((OffsetY)+pMCNK->GetLod(x, y));
			thisTri->Vertex[2].Z = ((OffsetZ)+(((y + 0.5) * 3.703703704)));	
			thisTri = thisTri + sizeof(thisTri);

			//First Vertex: Pos 19
			thisTri->Vertex[0].X = ((OffsetX)+(((x+1) * 3.703703704)));
			thisTri->Vertex[0].Y = ((OffsetY)+pMCNK->GetNoLod((x+1), (y+1)));
			thisTri->Vertex[0].Z = ((OffsetZ)+(((y+1) * 3.703703704)));	

			//Second Vertex: Pos 18
			thisTri->Vertex[1].X = ((OffsetX)+((x * 3.703703704)));
			thisTri->Vertex[1].Y = ((OffsetY)+pMCNK->GetNoLod(x, (y+1)));
			thisTri->Vertex[1].Z = ((OffsetZ)+(((y+1) * 3.703703704)));

			//Third Vertex: Pos 10
			thisTri->Vertex[2].X = ((OffsetX)+(((x + 0.5) * 3.703703704)));
			thisTri->Vertex[2].Y = ((OffsetY)+pMCNK->GetLod(x, y));
			thisTri->Vertex[2].Z = ((OffsetZ)+(((y + 0.5) * 3.703703704)));	
			thisTri = thisTri + sizeof(thisTri);
			
			//First Vertex: Pos 1
			thisTri->Vertex[0].X = ((OffsetX)+((x * 3.703703704)));
			thisTri->Vertex[0].Y = ((OffsetY)+pMCNK->GetNoLod(x, y));
			thisTri->Vertex[0].Z = ((OffsetZ)+((y * 3.703703704)));	

			//Second Vertex: Pos 18
			thisTri->Vertex[1].X = ((OffsetX)+((x * 3.703703704)));
			thisTri->Vertex[1].Y = ((OffsetY)+pMCNK->GetNoLod(x, (y+1)));
			thisTri->Vertex[1].Z = ((OffsetZ)+(((y+1) * 3.703703704)));

			//Third Vertex: Pos 10
			thisTri->Vertex[2].X = ((OffsetX)+(((x + 0.5) * 3.703703704)));
			thisTri->Vertex[2].Y = ((OffsetY)+pMCNK->GetLod(x, y));
			thisTri->Vertex[2].Z = ((OffsetZ)+(((y + 0.5) * 3.703703704)));	
			thisTri = thisTri + sizeof(thisTri);
			
		}
	}
	return 0;
}

[Salem]

	char *buffer = NULL;
	buffer = new char[sizeof(sTriangle) * 256];
	memset(buffer, '\0', sizeof(sTriangle) * 256);
	thisTri = (sTriangle*)buffer[0];
	thisObj = new sObject;a
	memset(thisObj, '\0', sizeof(sObject));

This kind of code is just plain ugly in a C++ program.

What is buffer?
If you wanted an array of triangles, why didn't you declare it with that type?
Casting one pointer to another could be landing you with alignment exceptions.

Further, I guess sObject is a class of some sort, in which case using memset to initialise it is a disaster. Use a constructor!




> for(int x = 0; x < 0; x++)
Does this loop even run at all?
Assuming that this is a typo (and this isn't your real code at all), then what is to stop this loop exceeding 256 entries (the magic number in your code above).

[cyberfish]

And be aware of the strict aliasing rule, though I believe in this specific case it's fine (doesn't mean it's a good idea).

[the4bidn]

All of the objects proceeded by s are structs and to the best of my knowledge the only way to null them is memset?

Also the loop was 8 in the code, I missed that before posting here.

I will change it back to a straight array which I was still having the same issue with.(256 is only a magic number until I get the code block working and implement a way for it to count prior to building the object)

[Elysia]

>>thisTri = (sTriangle*)buffer[0];
Why are you doing this? If you need some triangles, make some! But don't create some characters and pretend they're a triangle!
You're also setting yourself up for some hurt since you're using raw pointers. And what's wrong with std::vector?

[the4bidn]

Ok do I have a huge misunderstanding on the std::vector class is it slow to read from?

I was under the impression in C# it worked similar to linked lists.

I wrote a small project using vectors and it appears when I call reserve it stores stuff in sequential order in memory.

The idea which I thought was the old way to do things in C when absolute speed is needed is to create a buffer of any kind in memory the size or larger then you needed and use pointers to read and write raw data. However these is very dangerous I understand.

If I am reading thousands of triangles per second with a std::vector and the .at() method how is this going to hold up? I am testing it atm, but the application is only reading 256 triangles for simplicity.

[Elysia]

1) Vector and linked lists are two different things. Vectors are dynamic arrays. Data is stored contiguous in memory.
2) Vector is not slow to read from. It's just as fast as from a normal array. It cannot possibly be slower unless you are using the .at member function which performs a check to see if you access out-of-bounds.
3) Don't use any type--use the type you need. C++ is a type-strong language. Messing with chars and raw buffers is dangerous and not recommended.
4) Why don't you try with .at, with the index operator and w/o vector? Empirical results are the best, no?

[laserlight]

Ok do I have a huge misunderstanding on the std::vector class is it slow to read from?

I was under the impression in C# it worked similar to linked lists.

No, std::vector is a dynamic array container.

I wrote a small project using vectors and it appears when I call reserve it stores stuff in sequential order in memory.

Yes, though with reserve the objects do not actually exist; it is only space that is reserved for them.

The idea which I thought was the old way to do things in C when absolute speed is needed is to create a buffer of any kind in memory the size or larger then you needed and use pointers to read and write raw data. However these is very dangerous I understand.

It is not really dangerous if you do it right. Unfortunately, mistakes do happen. Anyway, with std::vector you can make the same kind of mistakes, except for the mistake of forgetting to free the memory.

If I am reading thousands of triangles per second with a std::vector and the .at() method how is this going to hold up?

You have to test and compare with your timing requirements. Admittedly, with at() boundary checking is performed, so the danger you mentioned is reduced, but the speed would be affected as well, yet it may still be fast enough.

[the4bidn]

Alright, thanks for the advice. I am gonna try use std::vector.at() unless I notice a performance hit being to large. As of now at ~50,000 triangles it still seems to be doing alright.