Memory problem

[kirenemook12]

no, and the strange thing is, the pointer is not being set to 4 any more.

[andywestken]

And has the access violaton gone, too?

[kirenemook12]

no, to bad it has not

[andywestken]

Have you tried commenting out code, as ComputerGeek01 suggested.

If the Cleanup()/exit code is OK, then something must be causing memory damage.

The fact that the 4 has gone might just mean the damage is happening somewhere else now.

[kirenemook12]

yes, i have tried to comment out the destructors.
so far as i know, that code is the only code that affects the memory, except the memory allocation code.

the cleanup code never gave a error

EDIT:

when i tried adding the deletion code before WinMain ends, gave me an exception.

i added the code like this

for(UINT i(0); i < vModels.size(); i++)// vModels is the vector with model pointers
	{
		if(vModels[i]->m_pIndexBuffer){vModels[i]->m_pIndexBuffer->Release();vModels[i]->m_pIndexBuffer = NULL;}
		if(vModels[i]->m_pVertexBuffer){vModels[i]->m_pVertexBuffer->Release();vModels[i]->m_pVertexBuffer = NULL;}
		if(vModels[i]->m_pTexture){vModels[i]->m_pTexture->Release();vModels[i]->m_pTexture = NULL;}
	

	}

it did not gave the error at vModels[0], but at vModels[3]. vModels[3] is the first model that was from a array.

the ecetion was a acces violation to 0xfeeefef6:

Unhandled exception at 0x00be5887 in NewStickFigWars.exe: 0xC0000005: Access violation reading location 0xfeeefef6.

i think that it is "no mans land" that is freed because if you add 8 to 0xFEEEFEEE, you get 0xfeeefef6 and the offset of the no mans land is 8.(http://www.nobugs.org/developer/win32/debug_crt_heap.html)
Edit:
i also found out that before that loop begins, every thing if fine, but when i = 3, the pointer in the m_pIndexBuffer and m_pTexture and m_pVertexbuffer change to feeefeee.

[andywestken]

it did not gave the error at vModels[0], but at vModels[3]. vModels[3] is the first model that was from a array.

Can you get your code to (easily) run with just the first three models?

And see if that hehaves OK?

Andy

[kirenemook12]

i have changed my code to this:

for(UINT i(0); i < 3; i++)
	{
		if(vModels[i]->m_pIndexBuffer)
		{
			vModels[i]->m_pIndexBuffer->Release();
		vModels[i]->m_pIndexBuffer = NULL;}
		if(vModels[i]->m_pVertexBuffer){vModels[i]->m_pVertexBuffer->Release();vModels[i]->m_pVertexBuffer = NULL;}
		if(vModels[i]->m_pTexture){vModels[i]->m_pTexture->Release();vModels[i]->m_pTexture = NULL;}
	}

the result is that i get the same error as before(0xC0000005: Access violation writing location 0xfeeefeee.)

[andywestken]

how do i stop the deconstructor from being called?

The short anwer to your question is : no.

This thread might be a of interest: "Should destructors be threadsafe?"
http://stackoverflow.com/questions/646427/should-destructors-be-threadsafe

I was going to suggest that one possible workaround was to move everything the destructor actually does out to an ancillary function, and use a flag so the destructor only calls this function if the control flag is still set. But I think you're already doing that with your clean-up function.

If not, it's worth a try as it should be quick to code. It won't solve the destructor firing issue, but might be enough to stop crash.

If not, you'll have to make the code thread safe. (From the article says, this would prob. be the right thing to do, even if you could avoid the prob. -- for now -- by using a flag mechanism.)

Andy

P.S. Another possibility is to convert your global to a pointer and handle the destruction youself. But this would prob. cause a lot of ripple, and might still need to be made thread safe.

[kirenemook12]

so far as i know, my program is thread safe. the main thread writes at the memory first, then it creates the second thread, and doesn't write to that memory anymore

[andywestken]

Well, the problem you described in your previous post does sound like the kind of thing they're discussing in the thread I posted a link to.

Might the global object's destructor be an exception?

The problem with it is that you have no way to control when the CRT calls the destructors of global objects when its going though its exit sequence.

[kirenemook12]

well, the problem in the thread you posted a link to is about deconstructors that delete things while they are still in use.
The problem here is that both threads call the deconstructors, causing things to get deleted twice.

i guess that you mean the vector of Model pointers with the "Global object", and in the callstack did i see that WinMain and the other thread calls the deconstructor,simultaneously

[andywestken]

Yes, I think that because your object is global, it's sort of "in use" until the app exits. As you said, two threads are trying to call it at the end, so both threads are still using it.

If I am following you correctly, vModels is an std::vector of Model classes declared at global scope.

I would prob. try moving this vector into a new "Model Manger" class, which is constructed on the heap. This would give you full control of the models life times.

This should relatively easy to do, with a smart enough IDE/editor. Plus a good backup strategy!

Andy

[kirenemook12]

i am going to try that

[kirenemook12]

that did not work.

even though there is only one thread deconstructing(the WinMain thread), the error happens before the deconstructor of the ModelManager class is called.

WinMain Looks like this:

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int  nCmdShow)
{
Model Tree;
Tree.LoadModelFromWaveFront("StickFigure.obj",D3DXVECTOR4(1,1,1,1),TheGame.m_pDevice);
//load some other models.....



   Model arrayModelTrees[7];
	for (UINT i(0); i < 7; i++)
		arrayModelTrees[i] = Tree1;

// do the same thing with the other models...


for(UINT i(0); i < 7; i++)
		vModels.push_back(&arrayModelTrees[i]);

// the same thing with the other models.


//create a timer:
timeGetDevCaps(&tc,sizeof(TIMECAPS));
	timeBeginPeriod(tc.wPeriodMin);
	TimerID = timeSetEvent(50,tc.wPeriodMin,TimerProc,NULL,TIME_PERIODIC);

// the Message Loop....
while(GetMessage(&msg,0,0,0) && MemoryLeakAlert(90) == false)
	{
		TranslateMessage(&msg);
		DispatchMessage(&msg);
		
	}


	boolTimerProc = false;// the Boolean variable that stops  TimerProc from working, if it is set to false, TimerProc stops the timer and returns
	



	return msg.wParam;

}

is it a possibility that arrayModelTrees is being destroyed ,and then are the pointers to the members of that array being destroyed, and with that, the array it self is being destroyed again?

[andywestken]

Hmmm...

In an earlier post you said that your models had global scope. But your listing of WinMain show that they have function level scope, which what I inferred from your stack trace.

As the class is not -- in fact -- a global, it means the issues I've mentioned are prob irrelevant: I have been talking about potential problems to do with the way the CRT exit code destroys global objects.

A quick spot check: is more than one thread being processed by your WinMain?

Andy

[kirenemook12]

how do you mean being processed?
and vModels is not declared in a function.

[andywestken]

But this is

Model arrayModelTrees[7];

If I read you code right, it looks like you're adding the addresses of local model instances (in arrayModelTrees, etc) to your global array, like this:

vModels.push_back(&arrayModelTrees[i]);

If vModels is storing pointers, they're pointing to memory which is owned by arrayModelTrees, etc.

[kirenemook12]

"A quick spot check: is more than one thread being processed by your WinMain?"

so far as i know, only one thread uses the WinMain function

[andywestken]

But does more than one thread use the global vModels.

[kirenemook12]

the problem is solved!!

the problem was in a line i thought was unimportant, I used memcopy() instead of the '=' operator, because in the beginning of the creation of my game, the '=' gave me a error, and memcopy did not.

i have replaced memcopy with the '=' operator, and it runs without errors.

thanks for your help, you have showed me lots of other ways to debug my program, thanks.

Erik