Singleton_pattern and Thread Safety

[Joshua Maurice]

The C library on all platforms has memory leaks?  Prove it.

I strive to write leak free code for any definition of leak.  As I have
already said Microsoft agree with me on the definition of a leak so it
is not a "Leigh Johnston memory leak" but a "memory leak".  End of
discussion.

Curious. I jumped to conclusions. I just tested it on my linux box.
Repeated loading and unloading of libc and the c++ std lib does not
result in increasing process size. I was wrong.

Test code:

//foo.c
int main();
void _start()
{
main();
asm("movl %eax,%ebx");
asm("movl $1, %eax");
asm("int $0x80");
}

#include <dlfcn.h>

int main()
{
for (;
{
void* libcpp = dlopen("/usr/lib64/libstdc++.so.6", RTLD_NOW |
RTLD_GLOBAL);
if ( ! libcpp)
return 7;
if (dlclose(libcpp))
return 8;
}

Compile and link command:
gcc foo.c -nostdlib -lgcc -ldl

In another test (not shown), I even malloc-ed a piece of memory with
malloc from dlsym, then free-ed it with free from dlsym, once per
loading of libc, in a tight loop. Again, no increase in process size.
This is most interesting.

 

[Miles Bader]

Personally, I'd go vaguer: "A memory leak is what you have when
deficiencies in your programs memory management cause so much memory
to be unnecessarily allocated that performance or results, of the
program or the system, is noticeably degraded." ....

Either way, it's not a program defect, because it does not affect
the correct and efficient behaviour of the program, which is what
actually matters.

Yup, although I'll note that I usually try to fix even harmless leaks
(e.g., a one-time leak of 1 byte), if only because they pollute
valgrind results when allowed to accumulate (one can also tell
valgrind to suppress reporting about particular leaks, but it's
generally more maintainable to just fix them).

-Miles