Question about malloc/free

[Special K]

If I forget to call free() on some allocated memory within my program, will the OS automatically free up all memory the program might have allocated when I exit the program?

 

[Templeton]

yes

 

[Neverm1nd]

depends on the os... but yes if it's fairly new (i.e. win9x might not)

 

[BFG10K]

Any operating system with dynamic memory allocation will do it.

 

[bsobel]

Originally posted by: Special K
If I forget to call free() on some allocated memory within my program, will the OS automatically free up all memory the program might have allocated when I exit the program?

The core question has been answered, but I need to ask why the inquirery, this is certainly not the way to design software.

 

[Madwand1]

Originally posted by: bsobel
The core question has been answered, but I need to ask why the inquirery, this is certainly not the way to design software.

Agree with that, and let me give one reason why: You're setting yourself up for memory leaks in the program. If you have a bunch of unfreed memory by design, then you'll miss any warnings about unfreed memory not by design at the end in the noise.

 

[Templeton]

Originally posted by: Madwand1

Originally posted by: bsobel
The core question has been answered, but I need to ask why the inquirery, this is certainly not the way to design software.

Agree with that, and let me give one reason why: You're setting yourself up for memory leaks in the program. If you have a bunch of unfreed memory by design, then you'll miss any warnings about unfreed memory not by design at the end in the noise.

I've got to disagree, it depends entirely on the program. There are many situations where you simply don't care about the memory that's lying around, it's faster to just exit when the user tells you to. This is especially true when the programs been unused for awhile with lots of memory paged out, why spend time to page memory back in just to free crap that the OS will reclaim for you?

 

[Madwand1]

Originally posted by: Templeton
I've got to disagree, it depends entirely on the program. There are many situations where you simply don't care about the memory that's lying around, it's faster to just exit when the user tells you to. This is especially true when the programs been unused for awhile with lots of memory paged out, why spend time to page memory back in just to free crap that the OS will reclaim for you?

It's a bad habit, which will typically lead to both memory leaks and the non-discovery of such memory leaks.

If you're really really concerned about exit speed, there are several possible remedies for that; none that really justify being sloppy with memory management in the first place. And if you have so much memory lying around that it really matters in speed, you should have some really good memory management habits, and leaving it to the OS to clean up your mess ain't among them.

I'd agree that in a trivial in & out program, memory retention would not be an issue. But in most serious applications, memory management and leak detection is an issue.

 

[Nothinman]

depends on the os... but yes if it's fairly new (i.e. win9x might not)

Actually the opposite would seem to be true, Win9X is the youngest OS that MS has produced. Their current offerings (i.e. XP and soon Vista) are all based off of NT which I think was first released in 93. And pretty much every unix system has a heritage back even farther.

 

[Special K]

Thanks for the replies. I went ahead and manually freed all of the memory myself. If I didn't, I was not able to run the program more than once without having to quit and exit again, because pointers would start walking all over each other and the program would crash.

I now have a related question. Suppose I do this (see code below):





Let's say that foo's return type is char* (pointer to char), and that the line I have is the initial declaration of tmp_ptr. Will I get into trouble by not allocating space to tmp_ptr before assigning it to the return value of foo(), or will that be handled automatically?

 

[UCJefe]

Originally posted by: Special K
Thanks for the replies. I went ahead and manually freed all of the memory myself. If I didn't, I was not able to run the program more than once without having to quit and exit again, because pointers would start walking all over each other and the program would crash.

I now have a related question. Suppose I do this (see code below):





Let's say that foo's return type is char* (pointer to char), and that the line I have is the initial declaration of tmp_ptr. Will I get into trouble by not allocating space to tmp_ptr before assigning it to the return value of foo(), or will that be handled automatically?

You have to allocate space. This is why many API's have a huge discussion in the documentation about who is responsible for allocating and freeing the memory. i.e. the caller, or the method itself. You don't get anything for free in an unmanaged language.

*edit* I realized I should have been more clear when I said "you" have to allocate space. I should have said "somebody" has to allocate space. Either foo can do it, or you as the caller can. Since this is a string returned from the method, foo is probably producing the string and as such, should probably allocate the memory itself. You can't take this for granted thugh so if foo is not your method, read the documentation.

 

[bsobel]

Based on the example giving, space for the char* (probably 4 or 8 bytes depending on your platform) will be automatically allocated form the stack. As such you do not need to specifically allocate storage for it.

 

[bsobel]

I've got to disagree, it depends entirely on the program. There are many situations where you simply don't care about the memory that's lying around, it's faster to just exit when the user tells you to. This is especially true when the programs been unused for awhile with lots of memory paged out, why spend time to page memory back in just to free crap that the OS will reclaim for you?

With the caviet that some small utility programs may not matter (run top to bottom and then exit), your simply encouraging sloppy development work. Someone with this attitude honestly wouldn't make it thru about 5 minutes of an interview, we'd simply show them the door.

Bill

p.s. To be fair, you could encourage him to just use java, c# or another gc language and make it a runtime porblem

 

[xtknight]

char *asdf = "this is a string";

In this example, 17 bytes (on ASCII platforms) are allocated for you (16 characters+1 null-terminator).

However, if you were to call foo, foo would have to allocate the space, or you would have to do it by using char asdf[50] for 49 characters (ASCII) and then by passing asdf, by reference, to foo.

Edit:...ASCII...ANSI?

 

[Markbnj]

why spend time to page memory back in just to free crap that the OS will reclaim for you?

Time? You mean the time spent writing the proper destructors, disposal, or finalization functions? It's not like the operating system is going to spend a lot of time marking your blocks free, and since the program is exiting, why would you care how long freeing memory takes? And since the memory has to be freed by the OS after the process terminates, it's not like you are actually saving any CPU/IO cycles.

I agree strongly with Madwand and Bsobel. You can rationalize that the operating system will clean up memory on exit, but whether that is "ok" or not depends on a number of artificial constraints: are all your objects created at startup and maintained for the duration of program execution? Do you never have a reason to deallocate memory while the program is running? If either of those things are not true then you are allocating memory at runtime, using it, and then failing to free it after it is no longer needed. This means that the working set of the process is larger than it should be, and has the potential to continue to grow as long as it is running. That working set is competing with all other processes for committed storage. It's just not good practice, and I would have a hard time respecting any programmer that thought it was the right thing to do.