Memory leak

[billt-lxSQFCZeNF4 at public.gmane.org]

 Shared memory is also a source of memory leaks. A program that doesn't deallocate the memory before exiting will cause that memory to stick around until reboot.

I have seen some weird memory leaks in multithreaded applications. A strange situation I remember was memory was allocated and shared by the threads via a global pointer. Sometimes a thread would allocate memory and use a global pointer, and before it was deallocated another thread would allocate memory and trash the first pointer. The memory the first pointer was pointing to is now a memory leak, but surprisingly the program didn't crash because of this. Some weird data ended up in Oracle though. The funny thing about this was the memory leak wasn't severe enough to notice, and it took weeks to figure out why garbage was being dumped into the database, because stepping through the debugger didn't exhibit this problem.

The joys of maintaining other peoples code.

Bill

On Sun, Dec 11, 2005 at 04:38:51PM -0500, Joseph Kubik wrote:
> Another exiting and popular leak is a program that for some reason
> opens sockets, or file handles of some sort and never releases the
> pointer. The FD / point / socket desciptor are not very large, however
> in some contexts a program cannot have more than a certian number of
> file handles.
> Sometimes netstat and lsof can help detect these types of leaks.
> -Joseph-
> 
> On 12/11/05, Peter <plp-ysDPMY98cNQDDBjDh4tngg at public.gmane.org> wrote:
> >
> > On Sun, 11 Dec 2005 wildberger-iRg7kjdsKiH3fQ9qLvQP4Q at public.gmane.org wrote:
> >
> > > On Sunday 11 December 2005 12:04 pm, billt-lxSQFCZeNF4 at public.gmane.org wrote:
> > >> Memory that is allocated using malloc or similar memory allocation system,
> > >> and not freed when it is no longer used.
> > > Now that I know what a memory leak is, my next question is:
> > > How does one know that one has a leak and how can one correct it.
> >
> > For a known application (like Firefox) it is known roughly how much
> > memory it will use as a maximum (say +/- 100%). If one sees it growing
> > beyond that, usually slowly and over lots of use, then it is suspect of
> > a memory leak. The growth can be seen in system table data (from /proc).
> > One way to look at it is with the 'top' program. Another is 'ps' with
> > suitable arguments. There are other more specialized tools for tracing
> > memory leaks (used mostly by programmers). For example right now my copy
> > of FF uses 53M RES, 10M SHR and 86M VIRT after 63 hours up but it is not
> > growing (the size change by a few megs depending on what pages I open
> > and close). These figures are from 'top'.
> >
> > Peter
> > --
> > The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
> > TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> > How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml
> >
> --
> The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml