SEGFAULT without extra processor

[treybgreen]

OpenDIS segfaults on IncomingMessage::SwitchOnType (called by IncomingMessage::Process). Have come across this once on Windows and once on RHEL. First was while processing the DetonationPdu on Windows and second time was while processing EntityStatePdu on RHEL. (Using DIS6)

open-dis-cpp/src/utils/IncomingMessage.cpp

Lines 42 to 78 in 63b22b6

	void IncomingMessage::SwitchOnType(DIS::PDUType pdu_type, DataStream& ds)
	{
	Pdu *pdu = NULL;
	PduBankContainer::iterator containerIter;
	// first, check if any custom PDU bank registered
	PduBankContainer::iterator pduBankIt = _pduBanks.find(pdu_type);
	if (pduBankIt != _pduBanks.end())
	{
	pdu = pduBankIt->second->GetStaticPDU(pdu_type, ds);
	} else
	{
	pdu = PduBank::GetStaticPDU(pdu_type);
	}
	// if valid pdu point, and at least 1 processor
	if (pdu && (_processors.count(pdu_type) > 0))
	{
	pdu->unmarshal( ds );
	// assumes the location in the buffer is the packet id.
	typedef std::pair<PacketProcessorContainer::iterator,PacketProcessorContainer::iterator> RangePair;
	RangePair rangepair = _processors.equal_range( pdu_type );
	PacketProcessorContainer::iterator processor_iter = rangepair.first;
	PacketProcessorContainer::iterator processor_end = rangepair.second;
	while( processor_iter != processor_end )
	{
	(processor_iter->second)->Process( *pdu );
	++processor_iter;
	}
	}
	else
	{
	ds.clear();
	}
	}

The problem was fixed when adding another processor leading me to believe somewhere the ->second reference is reading off the end, but I have not looked into the specifics. It was always the last processor that failed and I do not believe those two messages were to blame but wanted to note it.

[rodneyp290]

Hi @treybgreen, do you know if there is a reliable way to reproduce the error for debugging purposes?
If not, can you describe the conditions in which the error occurred? (i.e. rough traffic load - possibly per PDU type, number different PDU type processors used, etc)

[treybgreen]

Hi @treybgreen, do you know if there is a reliable way to reproduce the error for debugging purposes?

This bug is consistent every time I run my code. I'll see what I can get you @rodneyp290.