Strange Coding Problem

[ls612]

Oddly, no. Impossible. Came from the same build. PDB... maybe but unlikely as I'm now in the habit of keeping both in the assets folder and just copying both as a matter of process. I'll keep that in mind as a possibility though. Strangest darn thing... I may need to run it through the debugger with a stop on that portion to confirm for myself that the references are maintaining accuracy, if for no other reason than for my sanity alone .

You do know that the DLL and PDB in the PDB & DLL archive are outdated, right? calvitix didn't add his build's DLL and PDB to the archive folder, but he says he'll fix it soon.

 

[Thunderbrd]

That probably didn't help in my feeble debugging effort the other night but it doesn't affect the issue I was pointing out... that was on my own modding.

 

[AIAndy]

You know what? That was my patch in the interrim! I just wondered if that was the difference between the +/- Disease/round value and the total overall accumulated current value. Out of curiosity, I suppose I really should make sure I'm using the right tag in the first place here. I'm trying to call to the total, not the round by round modifying value. But I am a but curious what you'd use to ask for that value too, just so I know if I see it referenced what it means.

You can get the change to the properties in the last turn by using getChangeByProperty instead of getValueByProperty.

 

[Thunderbrd]

Ok, another issue has come up. Something I've done is creating a problem with a break in the core but last tracked in the code here:

void IFPBeginSample(ProfileSample* sample)
{
	if ( sample->Id == -1 )
	{
		if ( numSamples == MAX_SAMPLES )
		{
			dumpProfileStack();
			::MessageBox(NULL,"Profile sample limit exceeded","CvGameCore",MB_OK);
			return;
		}
		sample->Id = numSamples;
		sample->OpenProfiles = 0;
		sample->ProfileInstances = 0;
		sample->Accumulator.QuadPart = 0;
		sample->ChildrenSampleTime.QuadPart = 0;
		sampleList[numSamples++] = sample;
	}

	if ( ++depth == MAX_SAMPLES )
	{
		::MessageBox(NULL,"Sample stack overflow","CvGameCore",MB_OK);
	}
	else
	{
		sampleStack[depth] = sample;
	}

	sample->ProfileInstances++;
	sample->OpenProfiles++;

	if ( sample->OpenProfiles == 1 )
	{
		if ( _currentSample == NULL )
		{
			sample->Parent = -1;
		}
		else
		{
			sample->Parent = _currentSample->Id;
		}

		QueryPerformanceCounter(&sample->StartTime);
	}

	_currentSample = sample;

#ifdef DETAILED_TRACE
	if ( detailedTraceEnabled && lastExit != sample )
	{
		char buffer[300];

		if ( exitCount != 0 )
		{
			GenerateTabString(buffer, depth);
			sprintf(buffer+depth, "[%d]\n", exitCount);
			OutputDebugString(buffer);

			exitCount = 0;
		}

		GenerateTabString(buffer, depth);
		sprintf(buffer+depth, "-->%s\n", sample->Name);

		OutputDebugString(buffer);
	}
#endif
}

in GameCoredll.cpp (perhaps it goes without saying but I never touched this file with any changes.)

What could this be referring to? Am I overwhelming a text box somewhere? I'll have a bit of time to look into this tomorrow but wanted to see if you guys have any insight from running into this before.

 

[Koshling]

Ok, another issue has come up. Something I've done is creating a problem with a break in the core but last tracked in the code here:

void IFPBeginSample(ProfileSample* sample)
{
	if ( sample->Id == -1 )
	{
		if ( numSamples == MAX_SAMPLES )
		{
			dumpProfileStack();
			::MessageBox(NULL,"Profile sample limit exceeded","CvGameCore",MB_OK);
			return;
		}
		sample->Id = numSamples;
		sample->OpenProfiles = 0;
		sample->ProfileInstances = 0;
		sample->Accumulator.QuadPart = 0;
		sample->ChildrenSampleTime.QuadPart = 0;
		sampleList[numSamples++] = sample;
	}

	if ( ++depth == MAX_SAMPLES )
	{
		::MessageBox(NULL,"Sample stack overflow","CvGameCore",MB_OK);
	}
	else
	{
		sampleStack[depth] = sample;
	}

	sample->ProfileInstances++;
	sample->OpenProfiles++;

	if ( sample->OpenProfiles == 1 )
	{
		if ( _currentSample == NULL )
		{
			sample->Parent = -1;
		}
		else
		{
			sample->Parent = _currentSample->Id;
		}

		QueryPerformanceCounter(&sample->StartTime);
	}

	_currentSample = sample;

#ifdef DETAILED_TRACE
	if ( detailedTraceEnabled && lastExit != sample )
	{
		char buffer[300];

		if ( exitCount != 0 )
		{
			GenerateTabString(buffer, depth);
			sprintf(buffer+depth, "[%d]\n", exitCount);
			OutputDebugString(buffer);

			exitCount = 0;
		}

		GenerateTabString(buffer, depth);
		sprintf(buffer+depth, "-->%s\n", sample->Name);

		OutputDebugString(buffer);
	}
#endif
}

in GameCoredll.cpp (perhaps it goes without saying but I never touched this file with any changes.)

What could this be referring to? Am I overwhelming a text box somewhere? I'll have a bit of time to look into this tomorrow but wanted to see if you guys have any insight from running into this before.

That's the profiler. Depending on which message box is showing up (which is?), it's saying that a profile sample (usually a method, buit sometimes a sub-section) has been exitted without apparently being entered (which would actually be quite hard to do in most cases so I doubt you've done that accidentally), or that the stack depth of profile sections is deeper than it can handle (which would most likely be an infinite recursion bug in some code somewhere).

Would need to see a call stack and any details of messges it emits to diagnose further.

 

[Thunderbrd]

Ok. So in short, I've created an infinite loop in the data processing somewhere right? I can post the stack and where it errors later this evening... but I did have a suspicion earlier that I might be incidentally creating an infinite loop along the way so I'll also go see what I can do about that... hmm...

 

[Thunderbrd]

ack... I found an entirely different problem:

		iterator operator+(difference_type _Off) const
			{	// return this + integer
			iterator _Tmp = *this;
			return (_Tmp += _Off);
			}

breaking here... I must've set up those dang vectors wrong somehow because that's happening in CvPromotions apparently.
under threads:

0	>	507212	Main Thread	Main Thread	std::vector<CvPromotionInfo *,std::allocator<CvPromotionInfo *> >::iterator::operator+	Normal	0

the stack:

 	ntdll.dll!77d015de() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	ntdll.dll!77d015de() 	
 	ntdll.dll!77cf014e() 	
 	CvGameCoreDLL.dll!std::vector<CvPromotionInfo *,std::allocator<CvPromotionInfo *> >::iterator::operator+(int _Off=80440407)  Line 264 + 0xf bytes	C++
>	00000001()

I ran into this when trying to replicate the above issue to get more info to post.

Now... if I find the previous issue, are these the information bits you'd be looking for to be able to determine more?

 

[Koshling]

ack... I found an entirely different problem:

		iterator operator+(difference_type _Off) const
			{	// return this + integer
			iterator _Tmp = *this;
			return (_Tmp += _Off);
			}

breaking here... I must've set up those dang vectors wrong somehow because that's happening in CvPromotions apparently.
under threads:

0	>	507212	Main Thread	Main Thread	std::vector<CvPromotionInfo *,std::allocator<CvPromotionInfo *> >::iterator::operator+	Normal	0

the stack:

 	ntdll.dll!77d015de() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	ntdll.dll!77d015de() 	
 	ntdll.dll!77cf014e() 	
 	CvGameCoreDLL.dll!std::vector<CvPromotionInfo *,std::allocator<CvPromotionInfo *> >::iterator::operator+(int _Off=80440407)  Line 264 + 0xf bytes	C++
>	00000001()

I ran into this when trying to replicate the above issue to get more info to post.

Now... if I find the previous issue, are these the information bits you'd be looking for to be able to determine more?

Nope - that just tells me you're doing something wrong with the properties. Can you post the code that is doing teh property manipulation that isn't working (whatever is calling this, so higher up on the stack)

 

[Thunderbrd]

hmm... I gave you the whole stack so far as I had visibility on it. I was able to run past this one (unlike the other where it would ctd afterwards) and it came up against a problem in my NotOnGameOption tag for Promotions... All I could think of there was that the vector was either set up wrong or I am not calling to vector data correctly (which is very possible.) If the latter is true I could be having a problem in a number of areas here...

I'm curious what's telling you this has anything to do with properties? I'm seeing no clear reference to properties in any of that. (not doubting you... trying to understand.)

I may need to set up a branch off the svn so I can share my confudled coding with you... I seem to be having problems that are too indirect for me to understand where to address them.

If the problem IS in properties, the ONLY reference I've ever called to properties was the one this thread started with, and a slight restructuring of the onPropertyChange to create a necessary bypass... I'll post those both in just a bit here.

 

[Koshling]

hmm... I gave you the whole stack so far as I had visibility on it. I was able to run past this one (unlike the other where it would ctd afterwards) and it came up against a problem in my NotOnGameOption tag for Promotions... All I could think of there was that the vector was either set up wrong or I am not calling to vector data correctly (which is very possible.) If the latter is true I could be having a problem in a number of areas here...

I'm curious what's telling you this has anything to do with properties? I'm seeing no clear reference to properties in any of that. (not doubting you... trying to understand.)

I may need to set up a branch off the svn so I can share my confudled coding with you... I seem to be having problems that are too indirect for me to understand where to address them.

If the problem IS in properties, the ONLY reference I've ever called to properties was the one this thread started with, and a slight restructuring of the onPropertyChange to create a necessary bypass... I'll post those both in just a bit here.

I meant promotions, sorry. They sound/look too alike!

 

[Thunderbrd]

Ok... That was one of the few implemented tags since my last playtest and its quite reasonable that it seems to be showing some error spots. I'll take a bit to review all of that but I will return here with a post of some of the few coding spots that includes and see if you can see anything wrong.