I'm writing a winsock class, and it mostly works, but there are some bugs dealing with memory, and I can't figure out what the problem is. Is anyone willing to look at the code? It's a little long, but pretty self-explanitory.
Printable View
I'm writing a winsock class, and it mostly works, but there are some bugs dealing with memory, and I can't figure out what the problem is. Is anyone willing to look at the code? It's a little long, but pretty self-explanitory.
You should post the code that has the memory leak in it, then if someone posts telling you that they don't see any memory leaks then you will need to post the entire program to allow someone to check for memory leaks. Also you should concider buying a program that can check your code for memory leaks.
I believe these are the problem functions. I'm getting excess data sent(or received?). What kind of programs(names) deal with finding memory problems?
Code:INT PEER::ReadCRLF(CHAR *buff, size_t len)
{
char tmp = 0;
char prevtmp = 0;
char *zbuff = buff;
while (len > 0)
{
if ((iRecvBytes = recv(sckPeer, &tmp, 1, 0)) != 1)
{
if (iRecvBytes == 0)
{
iTRecvBytes += (int)strlen(buff);
return 0;
}
}
if (tmp == '\n')
{
if (prevtmp == '\r')
buff--;
*buff = '\0';
iTRecvBytes += (int)strlen(buff);
return 0;
}
*buff++ = tmp;
prevtmp = tmp;
len--;
}
iTRecvBytes += (int)strlen(buff);
return 0;
}
INT PEER::Send(CHAR *databuff, SOCKET sckUser)
{
if (wProtocol == TCP)
{
if ((iSentBytes = send(sckUser, databuff, (int)strlen(databuff), 0)) == SOCKET_ERROR)
if ((iError = WSAGetLastError()) != WSAEWOULDBLOCK)
return iError;
iTSentBytes += iSentBytes;
return iSentBytes;
}
return -1;
}
Parasoft has one called Insure++ at http://www.parasoft.com/jsp/products...eferred=google
LeakTracer at http://www.andreasen.org/LeakTracer/
On to your source. Why do you have a pointer to char pointing to the char* buff called zbuff, you never use it. Perhaps that is why? You are also *buff++ = tmp -- that is you are assinging tmp to *buff and then incrementing the buff pointer to point to the next element which when you call strlen(buff) it will be from the end of the buffer not the beginning as the buff pointer now is pointing to the element before the '\0' (null terminator) perhaps that is why you should have been using the zbuff pointer variable instead.
I did that fix, and am not sure if it helped any. It only seemed to delay the problem. Lots of data is sent and received, and with that fix, a little more can be sent/received but after a while I'm not sure what happens, but it stops working (not freezing or crashing, just doesn't work)
> *buff++ = tmp;
Your buff is not \0 terminated, so all your future calls to strlen() are broken
*buff++ = tmp; // add the char
*buff = '\0'; // keep it a proper string
> while (len > 0)
This does not allow space for the \0 to be added to an otherwise full buffer
You also need to consider the case where the buffer is full with '\r' as the last char, with '\n' being the first char in the next buffer.
IMO, it would be easier not to add the '\r' in the first place.
if ( tmp != '\r' ) // add to buffer
> iTRecvBytes += (int)strlen(buff);
What is this supposed to be doing?
[quote]
> iTRecvBytes += (int)strlen(buff);
What is this supposed to be doing?
[/quote
iTRecvBytes keeps total received bytes. I know this is a little, shady, but I just added it in.
So you're saying it should look like this? Earlier velius said I needed to use zbuff, but according to you, I keep it the way it is?:
Code:if (tmp == '\r')
{
*buff++ = '\n';
*buff++ = '\0';
return 0;
}
*buff++ = tmp;
*buff = '\0';
I'm saying it looked like you needed to use zbuff. It has no use and if it is not needed it should be removed.