[RESOLVED] memory leak in my memset usage?

Hello,

I have the following code that seems to generate a memory leak:

struct sockaddr_in serverAddr;
memset((char*)&serverAddr, 0, sizeof(_serverAddr));

I used a profiler to track the leak down to the memset call. It is only 1 block of memory, but I am wondering if I am using memset wrong?

Can anyone analyze this?

Thanks!

1. Why are you casting &serverAddr to char*? :confused:
2. What is _serverAddr? :confused::confused:
3. Define "seems to generate a memory leak". :rolleyes:

4. How do you check for memory leaks?

Quote:

---

Originally Posted by lab1

Can anyone analyze this?

---

It's bad coding. You shouldn't "null" a struct like that. Use a constructor instead, or an initialization method.

Not that I think you actually have a memory leak. It's probably just that the struct occupies more memory on the stack than you thought it would, but that's not a memory leak. I could be a result of data alignments performed by the compiler. For memory to be leaked it has to be allocated on the heap, otherwise leaking is imposssible.

this is standard code from tcp/ip examples. If it is bad code then it is in the Linux kernel as well as examples in all the major tcp/ip books.

_serverAddr is just serverAddr. The underscore was a typo in my paste.

I used glowcode 6.2 to find the memory leak.

I am casting &serverAddr to char* because thats how all the examples do it. The leak is there regardless if you cast it or not.

I am trying to create a very small sample program that will replicate the leak. i will post it here if possible.

Quote:

---

Originally Posted by lab1

this is standard code from tcp/ip examples. If it is bad code then it is in the Linux kernel as well as examples in all the major tcp/ip books.

---

Well, it's bad C++ code but I guess it's passable C code (The Linux kernel is writen in C).

Still, "nulling" a stack-allocated C struct cannot leak anything unless the struct holds some pointer to heap-allocated data.

What you consider a leak is caused by compiler induced allignement of the struct on the stack. It's just a question of "fitting". The "extra" memory used will be returned when the function returns.

ok memset was not the issue.. here is the most compact program I can generate that creates the leak:



Any idea why this code causes 1 block of memory to leak? Thanks!

There is no memory leak in that code.

I suspect you're trying to micro-manage memory usage----don't. That isn't your responsibility, it's that of the OS. The only memory you're responsible for managing is that which your code dynamically allocates. Since you don't do any dynamic allocation, you have no control over how much memory is used by the program.

Quote:

---

Originally Posted by lab1

Any idea why this code causes 1 block of memory to leak?

---

Does the leak go away if you remove that loop and call WSACleanup?

gg

Quote:

---

Originally Posted by lab1

Even the code below have the exact same leak:

---

You keep using the word. I do not think it means what you think it means.

Use my identical code and run it in a profiler. the socket() call contains a memory leak. You shouldnt say there is no leak unless you verify it. There is indeed a memory leak in the winsock socket() call.

A quick google will show you many other people have found this problem, but there is no answer yet.

In that case report the problem to the implementer.

Quote:

---

Originally Posted by lab1

Use my identical code and run it in a profiler. the socket() call contains a memory leak. You shouldnt say there is no leak unless you verify it. There is indeed a memory leak in the winsock socket() call.

A quick google will show you many other people have found this problem, but there is no answer yet.

---

What is this profiler you're referring to and what exactly is it saying?

I am using the lastest version of GlowCode 6.2. It says that there is a block of memory leaked when running my code as you see above. The leak is attributed to the socket() call.

Quote:

---

Originally Posted by lab1

Code:

---

#include <winsohck2.h>
#pragma comment(lib,"ws2_32.lib")

int main()
{
        WSADATA wsaData = {0};
        WSAStartup(MAKEWORD(2, 2), &wsaData);
        int _socket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
        closesocket(_socket);
        WSACleanup();
}

---

---

There is no memory leaks in this code.
The "scan the heap for memory leaks" doesn't matter until the main() returns.

There is either a memory leak in this code, or the Glowcode profiler is wrong. I dont understand how you can sit there and say there is no memory leak unless you run a profiler on it yourself.

Have you done that?

Many other people on google have had similiar problems with the winsock socket() call. Do a search.

Regards

Quote:

---

Originally Posted by lab1

There is either a memory leak in this code, or the Glowcode profiler is wrong. I dont understand how you can sit there and say there is no memory leak unless you run a profiler on it yourself.

Have you done that?

Many other people on google have had similiar problems with the winsock socket() call. Do a search.

Regards

---

Even if you're right, you're saying the problem is with the socket call and not your code. So what are you looking for here?

Quote:

---

Originally Posted by GCDEF

Even if you're right, you're saying the problem is with the socket call and not your code. So what are you looking for here?

---

Precisely. In my opinion, if you feel that you have found a memory leak in the implementation of socket(), then take the issue to the maintainer. Maybe it turns out that there really is such a bug, or maybe there is a bug in the memory leak detector.

Quote:

---

Originally Posted by lab1

I am using the lastest version of GlowCode 6.2. It says that there is a block of memory leaked when running my code as you see above. The leak is attributed to the socket() call.

---

Well, if some piece of code leaks memory it's a bug and you should contact the provider.

In this case it may be that the first call to socket allocates some global data which is then reused in further calls. You could repeatedly open/close the socket to check that possibility. Do it a 10.000 times or so while inspecting the memory allocation behaviour.

Quote:

---

Originally Posted by lab1

There is either a memory leak in this code, or the Glowcode profiler is wrong.

---

Many compilers provide source code to their runtime functions. Why not confirm it by debugging the source code to see if there really is a leak?

Anytime a programmer suspects a runtime function is faulty, and the programmer has the source code, do not say "bug" or "memory leak" without confirmation. You need to verify your claims by getting your hands dirty and seeing what's going on under the hood. Then you have solid information to give the provider (line of the source code, what goes on, etc.). GlowCode is not confirmation, as many of these third-party leak detectors have false positive reports.

If you can't verify it yourself, then you report it to the provider and say you suspect there is a problem, and not out and out say there is a memory leak or bug, as you have no real confirmation of that.

Regards,

Paul McKenzie

Thanks all!! Working on this now!