So while working away, I hit compile and then debug, and the app crashed at the outset. This is the same app that has been working fine for weeks. And the debugger is telling me that it crashes during a call to glDrawArrays - it sas it's trying to access 0x000000 address. The app has used this particular piece of code a million times before without incident, so I'm certain the problem lies elsewhere. Assuming I had done something screwy, I commented out the few lines of code I had added since the last successful test run, and tried again. It crashed in the same place. I did a clean rebuild. It still crashes in the same place. I manually removed all intermediate/object files and built again - same thing. Stepping through the program, it passes through the problem area once just fine, then the next time it calls it, it fails. Following the program execution I'm certain that nothing has happened to alter any of the openGL client states or anything else. In fact, the small bits of code that run between the first call to glDrawArrays and the second failing call are completely unrelated to the crashing code. This makes no sense whatsoever. What's more annoying is that it was working fine, and then I added a few lines, and it started crashing. So I removed those lines - so in theory it should be exactly back to where it was, but it isn't. This is a serious problem - I have absolutely no idea what could be the cause of this. I can only assume some kind of memory corruption is happening somewhere, but why is it crashing the app now and not before? Why when I commented out the lines and returned the program to it's last know good state, did it not make the problem go away?

0x000000 address usually means you have a null pointer you are trying to use somewhere in your code. maybe post the actual class the error falls in or as much of your code as possible that will help people help you with your problem.

hope that helps.

The code that crashes is this:

if (tex!=currentTexture)	{		glBindTexture(GL_TEXTURE_2D, texture[tex]);		currentTexture=tex;	}	glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);

but like I said, I know that the problem lies elsewhere because this piece of code has been running perfectly for weeks. It's the drawArrays line that crashes, so presumbly the vertex or uv coord pointers are messed up, so I changed it to this as a test:

if (tex!=currentTexture)	{		glBindTexture(GL_TEXTURE_2D, texture[tex]);		currentTexture=tex;	}	glVertexPointer(2, GL_FLOAT, 0, &vertexArray);	glTexCoordPointer(2, GL_FLOAT, 0, &texArrayQuad);	glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);

and running that causes a crash on the line:

glTexCoordPointer(2, GL_FLOAT, 0, &texArrayQuad);

again, saying it's trying to access 0x00000. However the variable texArrayQuad is showing up as fine in the debugger - it's non-NULL and has all it's values as expected. The function that these pieces of code reside in are global functions and so there's no way a NULL class pointer could be at fault.

Like I say, I'm certain that code is not the problem. Something must be causing openGL (or maybe something related to ogl) to reset a pointer, but as I said in my first post, I undid the changes I made between the app running fine and the app crashing, so I don't understand why it's still doing this. Although those few lines were completely unrelated to openGL, so maybe it's not something in ogl being reset. I am totally lost on this one.

Perhaps OGL is losing context? I'm not really sure what could cause that, especially right at the start of the program, but I guess it's something to look into at least.

out of curiosity, are you checking glGetError() during/after your 1st pass through the program (i.e. the 1st pass where it doesn't crash) to see if anything is wrong?

glGetError is returning no error on every gl call between the working run through that code and the failing run.

Unfortunately I'm an idiot and don't use source control. The last backup I have is about 5 days old, so there'll be tons of changes, so it could take another 5 days to go through them all and there'd still be no guarantee that I find the problem. As I said, I made only very minor changes between the app working fine and then crashing regularly, and those changes were this:

In a completely unrelated class, I added the lines:

                if (curUnit)		{			for (vector<Unit*>::iterator u=mapp->units.begin(); u<mapp->units.end(); u++)			{				if ((*u)->UnitIsAlliedWith(ET_Player))				{					FOWtiles.push_back(curUnit->pos);				}			}		}

I'm 99.9% positive that has nothing to do with the problem though - that code doesn't even get reached before the crash happens. And I tried commenting it out and still the crash happens.

And I haven't made any driver updates or installed any new libraries, or modified existing libraries.

This bug is just insane. It just doesn't make sense that it can make it through the first pass, but not the second. Between those two passes there is absolutely nothing that could affect the variables in use. And it's been working perfectly for weeks, so I would surely have to do something pretty stupid to get it to mess up this badly. Not that I'm not capable of such stupidity :)

I think you're going to have to track it down the tedious way by slowly commenting out "unrelated" bits of the program and boiling it down to the smallest possible case. If it really is as subtle as it sounds we're not going to be able to guess what it is from tiny code snippets.

Is there any software out there (preferrably free) that can parse two sets of C++ files and list the differences in terms of different functions, times where function contents don't match, variable names that don't exist on both sets, etc?