Thread: malloc doubt

Originally Posted by edesign

I don't have a free statement in between, when a second malloc is used what happens to the first allocation?

Nothing. If buffer was the only pointer to the memory previously allocated, you would then be unable to avoid a memory leak.

It is leaked. No doubt about that.

You should call free with the original value before you call malloc again.

--
Mats

Originally Posted by edesign

I also thought that it must be causing a leak, but was not so sure....

If you want to be sure, post also the code that you did not show. For example, this does not result in a memory leak despite having the pattern of what you showed us:

Code:

char *buffer;
char *buffer2;
buffer = malloc(some_amount);
buffer2 = buffer;
buffer = malloc(some_amount);
free(buffer);
free(buffer2);

It is always a leak if the memory is not freed correctly - it may be an INTENTIONAL leak or a unintentional leak, but it's a leak all the same.

--
Mats

Leaving intentional leaks in the code sucks. When somebody picks up your code months or years later, and runs it through a memory analyzer, this leak will appear, and that person will then waste their time determining where the bug is, ultimately discovering that it was intentional in the first place.

Even Microsoft's own libraries do this sometime. It makes it extremely difficult to write automated leak testing scripts, because you have to account for the leaks which are considered "ok," and these can change between releases of the libraries. So instead of the simple condition if num_leaks == 0: test_pass() you have some monstrosity which parses the results and figures out whether things are okay or not.

Originally Posted by nonoob

I stand corrected on the definition of 'leak'. To me the word leak implies an unintended program bug. Your definition includes any malloc which does not have a corresponding free before the termination of the program (which frees memory anyhow making the bug moot).

I would define "leaked" as any memory to which you no longer have access, because you lost the pointer. That is straight forward and unambiguous.

I would agree that as long as you still have access via a pointer, the memory is *not* leaked even if you do not free() it before termination. It may, however, be wasteful of resources. But there are other ways to do that, eg

Code:

char line[24000000];
printf("Enter your name: ");
fgets...line

which would not be called a leak.

Valgrind I believe calls anything not freed() lost memory, which makes valgrind very dumbass in my book. As brewbuck hints at, there are numerous very widely used libraries which do not pointlessly free() memory "at exit" rendering valgrind useless for mem profiling applications which use those libraries.

Originally Posted by nonoob

Your definition includes any malloc which does not have a corresponding free before the termination of the program (which frees memory anyhow making the bug moot).

Would you really want to use a program where the programmer tells you "You must terminate the program to stop it running out of memory resources"?

Not all operating systems seek to release memory, or other resources, used by a program as the program exits. Even in modern operating systems that do seek to release memory as a program exits, relying on that is one way to encounter obscure bugs in operating systems, and have those appear as vexing problem reports with your program.

Memory leaks are also a critical concern in long-running programs i.e. those which are required to run 24/7 and cannot be simply terminated and restarted. In such programs, memory leaks tend to show up in obscure manners such as unexplained slowdowns, lockups, or abnormal terminations.

Originally Posted by grumpy

Would you really want to use a program where the programmer tells you "You must terminate the program to stop it running out of memory resources"?

So what was the other option -- a program where the programmer assures you "Oh, this program does not use any resources while it is running." What you are saying does not make sense. Did you free() argv[0]? A running program uses memory. It will do so until terminated, unless you think writing a program that continues, doing nothing with nothing, is normative.

Not all operating systems seek to release memory, or other resources, used by a program as the program exits.

I am pretty sure you are wrong about that, because try as I might, I doubt I could write anything that would consume say, 200 MB, and then I terminate the process and re-run it until I am out of memory? No. I run the process, it takes 200 MB. I terminate the process, it takes 0 Mb. End of story. I could sit here all day trying, as long as I only have one instance, I won't consume more than 200 MB. Terminated processes release their memory.

Originally Posted by MK27

So what was the other option -- a program where the programmer assures you "Oh, this program does not use any resources while it is running." What you are saying does not make sense. Did you free() argv[0]? A running program uses memory. It will do so until terminated, unless you think writing a program that continues, doing nothing with nothing, is normative.

You missed his point. His point was that a program shouldn't be required to shut down to stop memory leaks, and he cited practical examples of programs that are required to run quite for long periods of time. He wasn't talking about using no resources, but simply running out of resources.... ie. leaking memory.

Whoever allocates should deallocate. argv is allocated by the underlying implementation, not your program, so your parallel is rather.... unfitting.

Originally Posted by MK27

I am pretty sure you are wrong about that, because try as I might, I doubt I could write anything that would consume say, 200 MB, and then I terminate the process and re-run it until I am out of memory? No. I run the process, it takes 200 MB. I terminate the process, it takes 0 Mb. End of story. I could sit here all day trying, as long as I only have one instance, I won't consume more than 200 MB. Terminated processes release their memory.

I believe it was Windows 98 that was discussed here some time ago that was discovered, at one point, to have a bug that lost malloc()ed memory that wasn't properly free()ed by the programmer, but I could be wrong on the details.

Modern operating systems are generally pretty good about details in subjects like these, at least better than operating systems used to be, but you can't always be sure what actually happens in an unknown OS when talking about C. His point was that if having a memory leak is potentially going to break an OS, don't do it.