Sign in to follow this  
UtMan88

_BLOCK_TYPE_IS_VALID(phead-nBlockUse) thrown in std::queue

Recommended Posts

So here's the scoop, and I'm pretty stumped over this one.

I have a message system. In a nutshell, this message system has a Windows std::queue in it (templated to use my abstract base message class). Once the message system is initialized and such, I call SendMsg(BaseMessage*) on it.

The call:
...
boids[i]->Update(fTime, flockCenter);
CollisionData* data = new CollisionData(this, boids[i]);
pmsg->SendMsg(new MSGCollisionCheck(data));
...

The function:
void MessageSystem::SendMsg(BaseMessage* pMsg)
{
// Make sure the message exists.
if (!pMsg) return;

// Send the message to the queue for processing later on.
m_MsgQueue.push(pMsg);
}

Then comes the problems:
From the call stack (from regular operation to crash):
> KM_Zombies.exe!std::queue<BaseMessage *,std::deque<BaseMessage *,std::allocator<BaseMessage *> > >::push(BaseMessage * const & _Val=0x0154d080) Line 73 C++

queue:
void push(const value_type& _Val)
{ // insert element at beginning
c.push_back(_Val);
}


> KM_Zombies.exe!std::deque<BaseMessage *,std::allocator<BaseMessage *> >::push_back(BaseMessage * const & _Val=0x0154d080) Line 827 C++

deque:
this->_Alval.construct(_Map[_Block] + _Newoff % _DEQUESIZ, _Val);


> KM_Zombies.exe!std::allocator<BaseMessage *>::construct(BaseMessage * * _Ptr=0xfeeefeee, BaseMessage * const & _Val=0x0154d080) Line 156 + 0xd bytes C++

xmemory:
void construct(pointer _Ptr, const _Ty& _Val)
{ // construct object at _Ptr with value _Val
_Construct(_Ptr, _Val);
}


And here's where we crash:
> KM_Zombies.exe!std::_Construct<BaseMessage *,BaseMessage *>(BaseMessage * * _Ptr=0xfeeefeee, BaseMessage * const & _Val=0x0154d080) Line 53 + 0x28 bytes C++

xmemory:
// TEMPLATE FUNCTION _Construct
template<class _T1,
class _T2> inline
void _Construct(_T1 _FARQ *_Ptr, const _T2& _Val)
{ // construct object at _Ptr with value _Val
void _FARQ *_Vptr = _Ptr;
::new (_Vptr) _T1(_Val);
}

Sometimes the call stack differs, but these are essentially the areas affected. I've looked to see where memory would be deleted twice, but I can't find anything of the sort in my code. Any suggestions?


Share this post


Link to post
Share on other sites
From my Boid System
void CBoidSystem::TASK_UpdateBoids(MessageSystem* pmsg, float fElapsed, std::vector<BOID*> boids)
{
unsigned int size = (unsigned int)boids.size();
float fTime = fElapsed;

for(unsigned int i = 0; i < size; ++i)
{
boids[i]->Update(fTime, flockCenter);
CollisionData* data = new CollisionData(this, boids[i]);
pmsg->SendMsg(new MSGCollisionCheck(data));
}
}

Note: This function is a thread task that is called from my thread pool.

Share this post


Link to post
Share on other sites
Quote:
Original post by UtMan88
Note: This function is a thread task that is called from my thread pool.


std::queue isn't thread safe in the sense that you can push and pop concurrently (or in any other sense really as the C++ standard makes no mention of threads).

Share this post


Link to post
Share on other sites
(Very good point. I will try replacing that queue with a thread-safe one I've created)

I made this demo program to test out a thread pool I've created (self-teaching myself multithreading). So what you mean to tell me is that if I call another function(child) FROM a task function(parent) called from another thread, that child is put on the same thread as the parent? (I've never been able to really prove this, and that is the point of this test and function :) )

Share this post


Link to post
Share on other sites
Suppose function A calls function B; A and B will always be on the same thread. The only way to cause code to run on another thread is by some form of message passing, or by spawning a new thread using the appropriate API.

Share this post


Link to post
Share on other sites
Quote:
Original post by ApochPiQ
Suppose function A calls function B; A and B will always be on the same thread. The only way to cause code to run on another thread is by some form of message passing, or by spawning a new thread using the appropriate API.


Rock on. OK I'll give that a test run...

... And it works! As a matter of fact, I'm pretty sure this covers a number of my problems involving the vectors and such.

Looks like someone's about to put this demo on Lock-down.

... Yeah... That was a threading joke.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this