a simple problem about memory allocation

[Nick]

excuse me!!

may i ask a simple problem here?

if i dynamically allocate a memory(ex. new in C++ or malloc in C)

in a sub-function and forget free the space end of the sub-function.

does it cause memory leak or the space automatically free by OS??

thx...

--
>> ¥xÆW¬ì¤j¸ê¤u¨t ²M¬y¯¸ # ntust.org #
>> Author from: dcs9.ee.ntust.edu.tw 

[Joona I Palaste]

Nick <ni******@ntust.org> scribbled the following:

excuse me!! may i ask a simple problem here? if i dynamically allocate a memory(ex. new in C++ or malloc in C)
C++ is off-topic here. C and malloc are on-topic though.
in a sub-function and forget free the space end of the sub-function. does it cause memory leak or the space automatically free by OS??
It causes a memory leak, unless you save the pointer in some other
variable and free the space afterwards in some other function.
thx...

Ur wlcm.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It's not survival of the fattest, it's survival of the fittest."
- Ludvig von Drake

[Richard Bos]

ni******@ntust.org (Nick) wrote:

if i dynamically allocate a memory(ex. new in C++ or malloc in C)
in a sub-function and forget free the space end of the sub-function.
does it cause memory leak or the space automatically free by OS??

That depends on the implementation. The vast majority of them will free
your memory for you when the program ends. However, since the calling OS
is beyond the scope of the Standard, this is not guaranteed.
It's still much better practice to clean up after yourself, of course,
if only because it's easier to maintain.

Richard

[Robert]

you loose that part of memory. as a good practice i recomend after you write
a code snipet for memory allocation imediatly after that write code snipet
to release it. always write these commands as pairs. than all the other code
write between those two code snipets.

[Mac]

On Fri, 07 Nov 2003 13:06:06 +0000, Nick wrote:

excuse me!!

may i ask a simple problem here?

if i dynamically allocate a memory(ex. new in C++ or malloc in C)

in a sub-function and forget free the space end of the sub-function.

does it cause memory leak or the space automatically free by OS??

thx...

There are really two cases to consider.

1) You use some memory, and you are not done with it until the program
terminates. Some people in this news group argue that in this case
it is OK to not free the memory, since the OS will reclaim it anyway.

2) Case 2 is different. In this case, you throw away your pointer to the
malloc'd memory without freeing it. This is a memory leak, and is always
wrong. Here is an example:

ptr = malloc(buff);

....

ptr = malloc(buff *= 2); /* memory leak here */
In the above example, ptr must be either freed or stored somewhere else
before the second call to malloc(). If you neither free it, nor save it,
then you lose the ability to free it, even if you want to.

HTH

Mac
--

[Freejack]

On Fri, 07 Nov 2003 07:40:27 -0500, Richard Bos wrote:

ni******@ntust.org (Nick) wrote:

if i dynamically allocate a memory(ex. new in C++ or malloc in C) in
a sub-function and forget free the space end of the sub-function.
does it cause memory leak or the space automatically free by OS??

That depends on the implementation. The vast majority of them will free
your memory for you when the program ends. However, since the calling OS
is beyond the scope of the Standard, this is not guaranteed. It's still
much better practice to clean up after yourself, of course, if only
because it's easier to maintain.

Richard

It's my understanding that the OS leaves the memory mapped to the
programs heap(or storage pool) and then draws from that pool for any new
malloc calls.

It's my understanding that the sequence works like this mmap() malloc()
[mlock() | munlock()] free() munmap()

So the only way to garauntee that the memory is reclaimed by the OS is to
unmap it after calling free().

Yes?

Freejack

[Mark Gordon]

On Sun, 09 Nov 2003 07:45:43 GMT
Freejack <us**@nospam.net> wrote:

<snip>

It's my understanding that the OS leaves the memory mapped to the
programs heap(or storage pool) and then draws from that pool for any
new malloc calls.
That is a common way to implement it, however it is not required to do
that.
It's my understanding that the sequence works like this mmap()
malloc()[mlock() | munlock()] free() munmap()

So the only way to garauntee that the memory is reclaimed by the OS is
to unmap it after calling free().

mmap, mlock, munlock and munmap are off topic since that are not part of
ISO C, however...

If you are using malloc to obtain memory then it won't be obtained from
memory *you* have mmap'ed. If you munmap memory that was malloced then
freed you are quite likely to crash you program since if it was not
mmap'ed (you don't know whether it was) that it is probably an invalid
operation and if it was mmap'ed then because you have gone behind the
implementations back it may well return you a pointer to the memory you
unmap'ed without having re-obtained the memory from the OS.

In other words, DON'T mix the system specific calls and the ISO C
library calls on the same objects.

I would suggest using malloc/free unless you have performance issues
which a profiler shows are due to the overhead of malloc/free, then
consider whether you can use malloc/free in a more efficient manner (say
by mallocing memory in larger chunks) and only as a last resort change
to using system specific calls.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.