Jump to content
  • Advertisement
Sign in to follow this  
_winterdyne_

A (possibly obvious) puzzle:

This topic is 4438 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Every so often I end up making a mistake that bites me in the arse, badly, and doesn't have the decency to be particularly obvious, to me at any rate. So I thought I'd post this one as a little brain teaser. There are three structs involved: MessageEntry, Message and Packet. I wonder how many of you will spot the bug, and guess why the error logger failed on its next call with an allocation problem in std::string?
// The fragment appears to be ok. Copy it into the awaiting message entry.
memcpy(
       (pMsgEntry->m_pMessage) + pPacket->m_iMsgOffset,
       (pPacket->m_Data),
	pPacket->m_iPacketSize);							
EDIT: Clue: The precise problem is a protection fault, with a heap block being modified after it has been freed...

Share this post


Link to post
Share on other sites
Advertisement
Not necessarily, there may be several packets, and they do not necessarily arrive in order. At this point,

(pPacket->m_iPacketSize + pPacket)->m_iMessageOffset < pMsgEntry->m_iMsgSize.


EDIT: And m_iMsgSize is the buffer size.

Share this post


Link to post
Share on other sites
(pMsgEntry->m_pMessage) + pPacket->m_iMsgOffset

iMsgOffset is probably an offset in bytes. This calculation does not give you a pointer that is iMsgOffset bytes past pMessage. If pMessage is a Message*, then this gives you pMessage + (iMsgOffset * sizeof(Message))


Also, I sure hope you're not copying stuff directly into a std::string. Why are you using memcpy anyway, and not std::copy?

Share this post


Link to post
Share on other sites
Ok, two people half way there! And they're editting posts as I type...

EDIT: No, the message is a binary struct containing data (which may be strings).

Actually, I suppose the offset being wrong gives it away - the mis-written packet data ends up being copied to the wrong place. The allocator in std::string in the logging function attempts to write over that packet and fails, as part of its block header has been overwritten making it look like it'd been freed.

What really confused me was the logging function that was failing was in a different thread, having nothing to do with the network thread.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!