Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Logical comparison of a DWORD and #define 0xXXXXXXXX


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
13 replies to this topic

#1 Tispe   Members   -  Reputation: 1038

Like
0Likes
Like

Posted 20 January 2013 - 05:21 AM

Hi

 

I have a std::vector<DWORD> that I want to loop through and compare each DWORD against a defined value. The problem is that either "&", "&&" or "==" will currupt the vector.

 

How can I do this check without messing up the vector?

 

#define StopLoadingThread	0xffffffff
std::vector<DWORD> LoadThread_RequestFiles;

 

for(int i=0;(int)LoadThread_RequestFiles.size();i++)
{
	if(LoadThread_RequestFiles[i] && StopLoadingThread)			//Fix comparison
	{
		m_quit = true;
	}
}
for(int i=0;(int)LoadThread_RequestFiles.size();i++)
{
	if(LoadThread_RequestFiles[i] == StopLoadingThread)			//Fix comparison
	{
		m_quit = true;
	}
}

 



Sponsor:

#2 Hodgman   Moderators   -  Reputation: 30938

Like
1Likes
Like

Posted 20 January 2013 - 05:32 AM

== should work fine.

 

Seeing the word "thread" appears in your code, the corruption is likely being caused by two threads accessing the vector at the same time... Can you explain what your threads are doing, and how you're synchronising them?



#3 Indifferent   Members   -  Reputation: 576

Like
2Likes
Like

Posted 20 January 2013 - 05:56 AM

for(int i=0;(int)LoadThread_RequestFiles.size();i++)

Ought to be:

for(size_t i = 0; i < LoadThread_RequestFiles.size(); i++)

You'll have to give more details on this apparent vector corruption but as Hodgman has said, it's possibly something to do with your threading.



#4 Tispe   Members   -  Reputation: 1038

Like
0Likes
Like

Posted 20 January 2013 - 06:06 AM

Well, there are 6 std::vectors<DWORD>, for buffered bi-directional communication. Two for Main thread, Two for Mutex and Two for the Load thread. The Main thread can call a function RequestFile(DWORD) which puts the DWORD value on the "send" vector. Another function (try)enters a mutex and copies from the "main_request" vector to the "mutex_request" vector. The loading thread will then enter the mutex and copy from the "mutex_vector" to the "LoadThread_RequestFiles" vector.

 

So the Main thread is the only one controlling the two main vectors and the loading thread is the only one controlling the thread_vectors. And there are two vectors in between main and thread can access via mutexes. The vector that gets corrupted is only accessed by the loading thread.

 

Send:

   MainReq_vector -> MutexReq_vector -> ThreadReq_vector

 

Recieve:

   MainCompleted_vector <- MutexCompleted_vector <- ThreadCompleted_vector



#5 Tispe   Members   -  Reputation: 1038

Like
0Likes
Like

Posted 20 January 2013 - 06:12 AM

I did this

for(size_t i = 0; i < LoadThread_RequestFiles.size(); i++)

But the result is the same.

void MyLoadingClass::GetRequestedFiles()
{
	EnterCriticalSection(&RequestLoadMutex);

	for(size_t i=0;i<Mutex_RequestFiles.size();i++)
	{
		LoadThread_RequestFiles.push_back(Mutex_RequestFiles[i]);		//Retrieves all requests from shared vector to loading thread
	}

	Mutex_RequestFiles.clear();										//Clear to prevent duplicates on next call
	LeaveCriticalSection(&RequestLoadMutex);
}


#6 ApochPiQ   Moderators   -  Reputation: 15997

Like
0Likes
Like

Posted 20 January 2013 - 06:30 AM

Threading bugs are evil. Just because variable Foo appears to be clobbered doesn't mean that the problem lies in code that handles Foo.

Check all of your thread synchronization and design. Chances are the problem is someplace else and/or rooted more deeply than just this vector.

#7 Tispe   Members   -  Reputation: 1038

Like
0Likes
Like

Posted 20 January 2013 - 06:32 AM

hmmm, I tried to copy the element to a test variable to see if it was the checking. Turns out that the act of copying the DWORD to test broke the vector.... How can that be.

 

	for(size_t i=0;i<LoadThread_RequestFiles.size();i++)
	{
		DWORD test = LoadThread_RequestFiles[i];			//Breaks LoadThread_RequestFiles
		if(test == StopLoadingThread)
		{
			m_quit = true;
		}


#8 Hodgman   Moderators   -  Reputation: 30938

Like
0Likes
Like

Posted 20 January 2013 - 06:57 AM

What do you mean exactly by broken and corrupted?



#9 Tispe   Members   -  Reputation: 1038

Like
0Likes
Like

Posted 20 January 2013 - 07:04 AM

Broken means that prior to

DWORD test = LoadThread_RequestFiles[i];

the vector containes the correct value and has a size of '1'. After this line of code the vector gets a size of '4260741497' and the elements value are just '(...,...,....)'.

 

I tried using iterator but the same thing happens:

 

	for(std::vector<DWORD>::iterator it = LoadThread_RequestFiles.begin(); it!= LoadThread_RequestFiles.end(); it++)
	{
		DWORD test = *it;						//does not work
		if(test == StopLoadingThread)			//Fix comparison
		{
			m_quit = true;
		}


#10 Khatharr   Crossbones+   -  Reputation: 3030

Like
0Likes
Like

Posted 20 January 2013 - 07:41 AM

Broken means that prior to
DWORD test = LoadThread_RequestFiles[i];

the vector containes the correct value and has a size of '1'. After this line of code the vector gets a size of '4260741497' and the elements value are just '(...,...,....)'.

 

?

 

Just a shot in the dark, but could you try cleaning and rebuilding the project? I want to say that I've run into this before but I can't remember what it was. I just vaguely remember stepping through the STL code with the debugger.


Edited by Khatharr, 20 January 2013 - 07:57 AM.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#11 ApochPiQ   Moderators   -  Reputation: 15997

Like
0Likes
Like

Posted 20 January 2013 - 10:37 AM

Also make sure you're not trying to debug a release build. That's a classic symptom of the debugger getting confused because of low-level optimizations.

#12 Matias Goldberg   Crossbones+   -  Reputation: 3564

Like
0Likes
Like

Posted 20 January 2013 - 12:50 PM

Multithreading is an extremely advanced topic. Make sure you first understand how STL template library works, how debugging applies to Debug & Release modes.

Also look for naming conventions. CamelCase is commonly used for functions (and sometimes variables, sometimes theyStartWithLowerCase but still camel case) and ALL_CAPS for macro definitions.

 

But mixing CamelCase with CamelCase_undercored_spaces is very weird and will confuse/annoy most coworkers you will encounter throughout your life.



#13 Tispe   Members   -  Reputation: 1038

Like
0Likes
Like

Posted 20 January 2013 - 01:43 PM

Ok, so I cleaned the solution and rebuilt everything again. And now it works. But that is strange because I already tried that several times. Why would that work on the 7th time....



#14 L. Spiro   Crossbones+   -  Reputation: 13958

Like
0Likes
Like

Posted 20 January 2013 - 03:03 PM

Because you rebuilt everything.  Meaning you updated object files that may not have been properly updated when they should have been.

Now every object file is “on the same page”.

 

 

L. Spiro


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS