Cherish every drop of water (memory debugging in KBMMW)

As a server-side application, the most basic requirement is stability, of course, to do a stable server side, need to involve a lot of aspects,

Memory leaks are a deadly killer of stability, because the server's physical memory is limited, even if a feature has a small memory leak, after

The long run will also accumulate into a very large memory leak, resulting in server memory exhaustion and system crashes. So Cherish server resources is

Developers have to pay attention to (of course, the memory can not be managed by the language and framework, that is even).

The latest version of the KBMMW has been added to the memory debugging function, which can not only be applied to the KBMMW server, you can also in other programs

Use.

In fact, since the beginning of Delphi 2007, Delphi uses FASTMM as the memory manager by default, and FASTMM also comes with memory leak reporting capabilities.

However, FASTMM can only trace memory resources allocated through GETMEM and cannot track memory (virtual/heap/global/local) allocated by Windows in other ways.

In addition, even if you block the FASTMM memory leak report, KBMMW's memory debugger can record memory usage at any time in the app.

We want to use KBMMW's memory debugging function, first to do the preparatory work.

First we're going to open kbmmwconfig.inc to join

{$DEFINE Kbmmw_support_debugmemory}
{$DEFINE Kbmmw_install_debugmemory_handlers}

These two terms are compiled in order to activate the KBMMW memory debugging feature, which is turned off by default.

If you do not have {$DEFINE kbmmw_support_debugmemory} This sentence, memory debugging does not work.

If there is no {$DEFINE kbmmw_install_debugmemory_handlers}, memory tracking does not work.

Now you can add the Kbmmwdebugmemory unit to your program, and your program will have a memory debugging function.

KBMMW automatically hooks up all the memory allocation functions in the Delphi program, including the previous BORLANDMM, and Windows own virtualxxx, Globalxxx,

Localxxx and heapxxx these functions. Of course, the FASTMM memory manager is also perfectly supported.

KBMMW for each memory allocation and memory redistribution is marked with a unique self-increment of 64 digits. With this number, we can track memory allocations over a period of time

, these points are called checkpoints. In principle, a checkpoint is a 64-digit number, which allows us to track each memory allocation.

KBMMW also maintains a statistical table of allocated memory and allocation times. You can check the statistics at any time.

procedureTform1.timer1timer (sender:tobject);beginlliveallocationscount.caption:=inttostr (Tkbmmwdebugmemory.liveallocationcount) +' ('+inttostr (TKBMMWDEBUGMEMORY.LIVEALLOCATIONCOUNTPERSEC) +'/sec)'; Lliveallocsize.caption:=inttostr (tkbmmwdebugmemory.liveallocationsize) +' ('+inttostr (TKBMMWDEBUGMEMORY.LIVEALLOCATIONSIZEPERSEC) +'/sec)'; Lmaxallocationcount.caption:=IntToStr (Tkbmmwdebugmemory.maxallocationcount); Lmaxallocationsize.caption:=IntToStr (tkbmmwdebugmemory.maxallocationsize); Lmaxcapacity.caption:=IntToStr (tkbmmwdebugmemory.currentallocationcountcapacity); Lcheckpoint.caption:=IntToStr (Fcheckpoint); Lgccount.caption:=IntToStr (TkbmMWDebugMemory.AllocationKeys.GCCount);End;

which

Liveallocationcount is of course used, active memory. It includes all (Borland-object/string/memory, Localmemory, Globalmemory, Virtualmemory, heapmemory).

Please refer to the source code of KBMMW for other parameters. Then buy a copy).

Knowing the memory allocation, the next step is to detect a memory leak after the program ends.

When did the memory leak?

Is the allocated memory that is never released.

Some memory leaks do not matter, because they occur only once throughout the application, a bit like defining a global variable, which is predictable and does not grow over time, such leaks in Delphi

There are many RTL and VCL, we can't destroy them, and there's no need to destroy them (for love, fish, these obsessive-compulsive patients are a nightmare).

For those memory leaks that occur with each execution, more and more time is spent, exhausting system resources and eventually causing the system to crash. So we have to destroy this leak.

Because memory tracing does not understand the idea of a person (I am not referring to "bamboo"), it is not possible to determine whether a piece of actively allocated memory really needs to be released during the program's run. So only when the program exits,

We know that the memory does need to be released, but not released. So you can only determine if the memory leaks when the program exits?

Inside the KBMMW, we can add memory detection in as early a place as possible.

Tkbmmwdebugmemory.reportdestination ('c:\temp\leaks.txt'); Tkbmmwdebugmemory.reportleaksonshutdown:=

We can do an obvious leak, test it.

procedure Tform1.button8click (sender:tobject); var    sl:tstringlist; begin   SL:=tstringlist. Create ; End;

Run the program, execute the above code, and then exit.

The following prompt is displayed:

If we go to see Leaks.txt

It will be obvious to find this problem.

The above information is sometimes very accurate, sometimes not necessarily accurate, mainly depends on your program compile some of the settings, especially the optimization code is very strong, will vary greatly.

Of course, memory usage and debugging involves a lot of things, if you want to go further, you can look at KBMMW source code and examples.

It is important to note that all of the above operations are at a cost, and if used in a formal production environment, try not to enable the Memory debugging feature.

Only when the memory leaks, it is recommended to use the above features to find the cause of leakage, eliminate the leak, immediately shut down the debugging function.

Cherish every drop of water (memory debugging in KBMMW)