[ wxwindows-Bugs-1739428 ] wxSocket returns erroneous data on blocking read

[SourceForge.net]

Bugs item #1739428, was opened at 2007-06-18 18:16
Message generated for change (Comment added) made by gorth
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1739428&group_id=9863

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Socket
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Private: No
Submitted By: Dan Kelly (gorth)
Assigned to: Nobody/Anonymous (nobody)
Summary: wxSocket returns erroneous data on blocking read

Initial Comment:
Using wxBase 2.8.3 and 2.8.4 on Linux with gcc 4.1.2

Occasionally (once in every 10-50 reads) a Read() on a socket with flags wxSOCKET_BLOCK | wxSOCKET_WAITALL will return with no error and the expected readlength, but the data it returns is that from the last call to Write().

The client recieved the data from Write() and wrote a response that has different data.

I've only been able to replicate the issue in a complex server with multiple threads running.  Only a single thread has access to each socket.  The error does occur with only one socket connected.

The following code results in the isssue, but not every execution.

m_Sock->Write(ciphertext, m_lastcount+cryptlen);
if(m_Sock->Error())
{
	return;
}

	
//Some lines of non-socket/non-wx code	

m_Sock->SetFlags(wxSOCKET_BLOCK | wxSOCKET_WAITALL);
memset(ciphertext, 0, 8);
cryptlen = 0;
	
m_Sock->Read(ciphertext, 8);
if(m_Sock->Error())
{
	wxLogDebug(_("Read Error: %d"), 
m_Sock->LastError());
	return;
}

cryptlen = m_Sock->LastCount();

//No error here, cryptlen will read 8
//ciphertext may or may not have the right data
//probability of getting wrong data seems to go down
//with increasing load on the machine


----------------------------------------------------------------------

>Comment By: Dan Kelly (gorth)
Date: 2007-07-12 18:03

Message:
Logged In: YES 
user_id=33247
Originator: YES

Turned out to be a nasty race condition in other code that caused
duplicate data to be written.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1739428&group_id=9863