Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #12057 > unrolled thread

Memory Management Question

Back to article view | Back to comp.lang.c++

Contents

  Memory Management Question Nephi Immortal <immortalnephi@gmail.com> - 2011-12-04 17:55 -0800
    Re: Memory Management Question Robert Wessel <robertwessel2@yahoo.com> - 2011-12-05 01:07 -0600
    Re: Memory Management Question Goran <goran.pusic@gmail.com> - 2011-12-05 00:06 -0800
      Re: Memory Management Question Christopher <cpisz@austin.rr.com> - 2011-12-07 16:13 -0800
        Re: Memory Management Question Goran <goran.pusic@gmail.com> - 2011-12-08 03:00 -0800
    Re: Memory Management Question Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-05 00:37 -0800
      Re: Memory Management Question Juha Nieminen <nospam@thanks.invalid> - 2011-12-05 13:17 +0000
        Re: Memory Management Question Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-12-07 20:03 +0000
          Re: Memory Management Question 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-07 21:35 -0800
        Re: Memory Management Question jgk@panix.com (Joe keane) - 2011-12-16 02:26 +0000

#12057 — Memory Management Question

Can you please be kind to answer my question?  I know that it is not C+
+ topic on this newsgroups.  I did a lot of researches, but I did not
find valuable information.

First question:

	After you allocate memory using new function, you accidently call
delete function twice.  It causes to have memory leak.  The C++
program exit main function before it calls EndProcess function
(probably Win32 API).  Can EndProcess deallocate some objects and
memory leaks automatically?  Memory leaks will not affect another
applications or resources.
	Sometimes, terminate function or abort function do not release some
allocated objects can cause memory leaks prior EndProcess.  The client
will require to reboot operating system to clear up all available
memory.
	Please confirm if I am correct.

Second question:

	When you create free heap object, how many bytes do free heap object
take allocated memory before you use new function to allocate small or
large array.

	For example, you allocate 16 bytes.  Heap reserves extra 8 bytes.
One is for array pointer and another one is for heap pointer.
Perhaps, extra 16 bytes.

	You can allocate multiple 16-byte arrays or 256 16-byte arrays.  The
total 256 16-byte arrays is 4,096 bytes.  Heap object might reserve
extra 2,048 bytes for all 256 16-byte arrays.

	I am interested to know more.  If you have information, please
provide me website.

[toc] | [next] | [standalone]

#12062

On Sun, 4 Dec 2011 17:55:29 -0800 (PST), Nephi Immortal
<immortalnephi@gmail.com> wrote:

>Can you please be kind to answer my question?  I know that it is not C+
>+ topic on this newsgroups.  I did a lot of researches, but I did not
>find valuable information.
>
>First question:
>
>	After you allocate memory using new function, you accidently call
>delete function twice.  It causes to have memory leak.  The C++
>program exit main function before it calls EndProcess function
>(probably Win32 API).  Can EndProcess deallocate some objects and
>memory leaks automatically?  Memory leaks will not affect another
>applications or resources.
>	Sometimes, terminate function or abort function do not release some
>allocated objects can cause memory leaks prior EndProcess.  The client
>will require to reboot operating system to clear up all available
>memory.
>	Please confirm if I am correct.


Most hosted systems, certainly not all - but most, will clean up
memory allocated by the process when it terminates.  If nothing else,
systems that implement a separate address space for each process tend
to get cleaned up because the address space gets deleted by the OS
after the process terminates.  Windows largely does that as well.

Of course any such cleanup avoids dtors and whatnot.  Nor is it
actually demanded by the standard.


>Second question:
>
>	When you create free heap object, how many bytes do free heap object
>take allocated memory before you use new function to allocate small or
>large array.
>
>	For example, you allocate 16 bytes.  Heap reserves extra 8 bytes.
>One is for array pointer and another one is for heap pointer.
>Perhaps, extra 16 bytes.
>
>	You can allocate multiple 16-byte arrays or 256 16-byte arrays.  The
>total 256 16-byte arrays is 4,096 bytes.  Heap object might reserve
>extra 2,048 bytes for all 256 16-byte arrays.
>
>	I am interested to know more.  If you have information, please
>provide me website.


It's entirely implementation defined.  Many systems have considerably
different policies for allocating large and small objects, and in
particular very small and very large objects.  That being said, as a
general rule (and so long as you avoid extreme sizes and certain
fragmentation patterns) allocating the same amount of storage with
fewer, but larger, allocations is usually more efficient than more,
but smaller allocations.  But again, it's quite implementation
dependent, and there are often corner cases.

[toc] | [prev] | [next] | [standalone]

#12065

On Dec 5, 2:55 am, Nephi Immortal <immortalne...@gmail.com> wrote:
> Can you please be kind to answer my question?  I know that it is not C+
> + topic on this newsgroups.  I did a lot of researches, but I did not
> find valuable information.
>
> First question:
>
>         After you allocate memory using new function, you accidently call
> delete function twice.  It causes to have memory leak.

Not true. This causes undefined behavior.

>  The C++
> program exit main function before it calls EndProcess function
> (probably Win32 API).  Can EndProcess deallocate some objects and
> memory leaks automatically?  Memory leaks will not affect another
> applications or resources.

Yes, under Windows, Unix variants and other systems where exists a
thing known as a "process isolation". Such systems take on to free any
resources allocated by the program when program terminates. THat goes
not only for memory, but for all kinds of operating system resources
(files, sockets, mutexes...).

>         Sometimes, terminate function or abort function do not release some
> allocated objects can cause memory leaks prior EndProcess.

Only if there is a bug in the operating system. However, these are
very, very rare occurrences in today's systems.

> The client
> will require to reboot operating system to clear up all available
> memory.

Yes, if indeed there is a bug. However, there is a very, very small
chance of that, compared to the chance that e.g. you are seeing weird
beh

>
> Second question:
>
>         When you create free heap object, how many bytes do free heap object
> take allocated memory before you use new function to allocate small or
> large array.
>
>         For example, you allocate 16 bytes.  Heap reserves extra 8 bytes.
> One is for array pointer and another one is for heap pointer.
> Perhaps, extra 16 bytes.

That depends on your system. There's nothing in C++ language that can
tell you this. Extra 16 bytes sounds reasonable on a 32-bit system,
though.

>
>         You can allocate multiple 16-byte arrays or 256 16-byte arrays.  The
> total 256 16-byte arrays is 4,096 bytes.  Heap object might reserve
> extra 2,048 bytes for all 256 16-byte arrays.
>
>         I am interested to know more.  If you have information, please
> provide me website.

You need to know how heap handling is implemented in the library you
use (typically, C runtime that comes with your compiler). Ask there.
However, know this: any information is volatile and subject to change
over time.

Goran.

[toc] | [prev] | [next] | [standalone]

#12138

On Dec 5, 2:06 am, Goran <goran.pu...@gmail.com> wrote:
> Yes, under Windows, Unix variants and other systems where exists a
> thing known as a "process isolation". Such systems take on to free any
> resources allocated by the program when program terminates. THat goes
> not only for memory, but for all kinds of operating system resources
> (files, sockets, mutexes...).

I've got quite a few executables that if run 10+ times and allowed to
crash 10+ times, will bring XP to a crawl.
Process Explorer shows the process exited, yet the system is no longer
as responsive and won't be until a reboot.

What possible reason could there be aside from some resource getting
used and not reclaimed?

Throw COM in the mix and you've got processes that were started by
other processes! Then your program can really do some damage even
after exit.

[toc] | [prev] | [next] | [standalone]

#12157

On Dec 8, 1:13 am, Christopher <cp...@austin.rr.com> wrote:
> On Dec 5, 2:06 am, Goran <goran.pu...@gmail.com> wrote:
>
> > Yes, under Windows, Unix variants and other systems where exists a
> > thing known as a "process isolation". Such systems take on to free any
> > resources allocated by the program when program terminates. THat goes
> > not only for memory, but for all kinds of operating system resources
> > (files, sockets, mutexes...).
>
> I've got quite a few executables that if run 10+ times and allowed to
> crash 10+ times, will bring XP to a crawl.
> Process Explorer shows the process exited, yet the system is no longer
> as responsive and won't be until a reboot.

What kinds of OS resources they handle and how?

You might, of course, be hitting an OS bug, but without knowing more,
I am inclined to say "you don't know what your processes are doing".

> What possible reason could there be aside from some resource getting
> used and not reclaimed?

Did you look at resource usage (even TaskManager can show you some of
that)? Without info, who knows. It's mighty improbable that the reason
indeed is an OS bug (compared to the probability that it's code
running atop of the OS that causes the slowdown).

> Throw COM in the mix and you've got processes that were started by
> other processes! Then your program can really do some damage even
> after exit.

Unless you hit an OS bug, my claim is that you can't.

One thing you might try is to restart the shell (Explorer.exe). That's
because you might have OS resources being passed onto explorer through
COM and shell extensions.

Goran.

[toc] | [prev] | [next] | [standalone]

#12066

On Dec 5, 1:55 am, Nephi Immortal <immortalne...@gmail.com> wrote:

> Can you please be kind to answer my question?  I know that it is not C+
> + topic on this newsgroups.  I did a lot of researches, but I did not
> find valuable information.
>
> First question:
>
>         After you allocate memory using new function, you accidently call
> delete function twice.

Don't Do This. It's Undefined Behaviour which simply means the
standard places no obligation on the impelmentor, he do what he damn
well pleases. Crashing or trashing the heap are likely possibilities.

> It causes to have memory leak.

unlikely

> The C++
> program exit main function before it calls EndProcess function
> (probably Win32 API).  Can EndProcess deallocate some objects and
> memory leaks automatically?  Memory leaks will not affect another
> applications or resources.

as others have stated modern OSs clean up on exit. This includes
Windows XP and anything that came after it, Linux and MacOS.

<snip>

> Second question:
>
>         When you create free heap object, how many bytes do free heap object
> take allocated memory [...]

very implementaion dependent. I'd say 4 bytes per allocation but
other's are quoting more. There may be more bytes for alignment. (a 32-
bit integer may have to start on an address divisible by 4).

> [...] before you use new function to allocate small or
> large array.

don't get this bit

>         For example, you allocate 16 bytes.  Heap reserves extra 8 bytes.
> One is for array pointer and another one is for heap pointer.

what is this "array pointer" of which you speak?

> Perhaps, extra 16 bytes.

sounds a lot

>         You can allocate multiple 16-byte arrays or 256 16-byte arrays.

what?

>  The
> total 256 16-byte arrays is 4,096 bytes.  Heap object might reserve
> extra 2,048 bytes for all 256 16-byte arrays.
>
>         I am interested to know more.  If you have information, please
> provide me website.

Have you tried your implementaiosn documentaion. I've always found
MSDN quite reasonable

[toc] | [prev] | [next] | [standalone]

#12071

Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> as others have stated modern OSs clean up on exit. This includes
> Windows XP and anything that came after it, Linux and MacOS.

  I don't know why, but I find the notion that an OS would not free the
resources reserved by a process so antiquated that it's almost amusing.

  In most systems when you do a "new" (or "malloc()" or whatever), that's
*not* a system call (ie. a call to the operating system). It simply causes
the C runtime environment to allocate a block of memory from the heap.
The heap is something that's not managed by the code that the programmer
writes. It's managed by the C runtime environment (eg. in most unix systems
it would be the libc.so shared library). This runtime interacts with the
operating system, and it happens by the runtime, basically, saying to the
OS "hey, increase my heap by this much" (which is usually a bigger chunk
than what was requested by the code) when the runtime needs more heap.

  When the program ends, the runtime usually just tells the OS "I don't
need this heap anymore". It doesn't matter whether the code has forgotten
some deletes or not. It all goes away when the program ends.

  Even if the program is for some reason killed abruptly (eg. by sending
it SIGKILL), the OS will remove the process and take its heap back. Again,
whether the program code forgot some deletes is completely irrelevant.
That memory management is at a completely different level.

  In short: The OS sees the memory taken by a process just one big chunk
of heap. The OS couldn't care less how the program uses that heap. If the
program internally "leaks" objects inside the heap, that's completely
inconsequential. When the program ends, it takes that heap back (if the
runtime didn't release it explicitly) and that's it.

  The reason why leaks are bad is if they happen in a loop or slowly over
long periods of time. This will cause the runtime to request more and more
heap space from the OS, consuming physical RAM and eventually running out
of it.

  There are other resources that are much closer to the notion that the
program requests the OS directly a resource and the OS has then to release
it if the program itself doesn't. These may include (depending on the OS)
things like file handles (although these are often also process-specific
and not systemwide) and sockets. Temporary files are an interesting case
as well (if the temp file was requested from the OS).

[toc] | [prev] | [next] | [standalone]

#12124

On Mon, 2011-12-05, Juha Nieminen wrote:
> Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
>> as others have stated modern OSs clean up on exit. This includes
>> Windows XP and anything that came after it, Linux and MacOS.
>
>   I don't know why, but I find the notion that an OS would not free the
> resources reserved by a process so antiquated that it's almost amusing.

Your view is narrow.  There are interesting things you can easily do
if there's no explicit ownership of memory -- it's just that those of
us who have used Real OSes for ~15 years have forgotten about it.

I have forgotten too, but I remember back when I thought virtual
memory etc was just a way to throw hardware at a problem which was
really about sloppy programming ...

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#12144

On Thursday, December 8, 2011 4:03:05 AM UTC+8, Jorgen Grahn wrote:
> On Mon, 2011-12-05, Juha Nieminen wrote:
> > Nick Keighley <nick_keigh...@hotmail.com> wrote:
> >> as others have stated modern OSs clean up on exit. This includes
> >> Windows XP and anything that came after it, Linux and MacOS.
> >
> >   I don't know why, but I find the notion that an OS would not free the
> > resources reserved by a process so antiquated that it's almost amusing.
> 
> Your view is narrow.  There are interesting things you can easily do
> if there's no explicit ownership of memory -- it's just that those of
> us who have used Real OSes for ~15 years have forgotten about it.
> 
> I have forgotten too, but I remember back when I thought virtual
> memory etc was just a way to throw hardware at a problem which was
> really about sloppy programming ...
> 
> /Jorgen
> 
Well, the large  virtual mode address space  of the heap is cheating  
some novice programmers to think that a lousy big chunk returned from malloc 
or new  can really use more than a page of the real memory in the heap of the OS which talks to the hardware directly without any overheads. 




> -- 
>   // Jorgen Grahn <grahn@  Oo  o.   .     .
> \X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#12562

In article <4edcc46e$0$3065$7b1e8fa0@news.nbl.fi>,
Juha Nieminen  <nospam@thanks.invalid> wrote:
>  I don't know why, but I find the notion that an OS would not free the
>resources reserved by a process so antiquated that it's almost amusing.

It will release process-specific VM, and close file descriptors, but
that doesn't mean it solves all your problems.

a) process creates a file, it intends to delete it when it's done, but
if it crashes the file is still there

b) lots more cases i can think of

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web