topic "This is test:";
[a83;*R6 $$1,3#31310162474203024125188417583966:caption]
[H4;b83;*4 $$2,3#07864147445237544204411237157677:title]
[b42;a42;ph2 $$3,3#45413000475342174754091244180557:text]
[l321;C@5;1 $$4,4#20902679421464641399138805415013:code]
[ $$0,0#00000000000000000000000000000000:Default]
[{_}%EN-US 
[s1; Resolving memory leaks in U`+`+ applications&]
[s2; Table of contents&]
[s0; &]
[s0; [^topic`:`/`/Core`/srcdoc`/Leaks`_en`-us`#1^ 1. Introduction]&]
[s0; [^topic`:`/`/Core`/srcdoc`/Leaks`_en`-us`#2^ 2. Debugging leaks]&]
[s0; [^topic`:`/`/Core`/srcdoc`/Leaks`_en`-us`#3^ 3. False positives]&]
[s0; &]
[s2;:1: 1. Introduction&]
[s3; Before 2008.1 release, the memory leaks debugging facilities 
have changed. Here we try to explain why logic has changed and 
what problem is it supposed to solve:&]
[s3; Previous method involved watching for particular ADDRESS to 
be allocated (so that you could determine the source of leak). 
Anyway, that has a problem than often the same memory block is 
going to be allocated more than one time `- obviously, in that 
case the watch would only catch the first allocation, which would 
not be the cause of the problem. That is why logic was improved 
by introducing `"memory allocation serial number`".&]
[s3; The memory leaks mechanisms only applies to U`+`+ Core based 
application. When you develop non U`+`+ applications in TheIDE, 
the detection mechanism will not be present.&]
[s2;:2: 2. Debugging leaks&]
[s3;~~~2752; In `"memory allocation serial number`" each memory allocation 
has associated serial number (incremental). When U`+`+ detects 
a leak, it dumps all leak blocks (note that sometimes you can 
resolve the problem just by examining its content) to standard 
.log file. You can see it in TheIDE by pressing[*  Alt`+L] or by 
selecting [* `"View log file`"] option from `"Debug`" menu:&]
[s0; &]
[s0;= 
@@rawimage:2230&1400
([encoded data, 49780 characters])
&]
[s0; &]
[s3;~~~2752; In the .log, serial number is printed for each leaked 
memory block. It is printed after `"`-`-memory`-breakpoint`_`_`":&]
[s0; &]
[s0;= 
@@rawimage:3768&922
([encoded data, 57700 characters])
&]
[s0; &]
[s3; Now the only thing you need to do is to add `"void [* MemoryBreakpoint](dword 
serial)`" call to your application source code. For the case 
above the serial parameter should 925. When Alloc for that serial 
happens again, `_`_BREAK`_`_ will segfault (`"`*(void `*)0 `= 
0`") the application and you will be able to catch the problem 
in the debugger. The code that will detect the leak could look 
like this:&]
[s0; &]
[s4; #include <Core/Core.h>&]
[s4; &]
[s4; using namespace Upp;&]
[s4; &]
[s4; CONSOLE`_APP`_MAIN&]
[s4; `{&]
[s4; -|MemoryBreakpoint(925); [@(28.127.0) // <`- The earlier you place 
this instruction the better]&]
[s4; -|&]
[s4; -|int`* a `= new int(5); [@(28.170.0)   ][@(28.127.0) // <`- Debugger 
should break in this line]&]
[s4; `}&]
[s3; &]
[s3; The alternative approach assumes that the `"`-`-memory`-breakpoint`_`_`" 
is passed as a program argument. In this case there is no need 
to modify source code. To do it open `"Run options`" dialog from 
`"Debug`" menu:&]
[s0; &]
[s0;= 
@@rawimage:2309&1620
([encoded data, 44672 characters])
&]
[s0; &]
[s3; Now the window where command line arguments for application 
can be specified should appears. In this case we need to add 
`"`-`-memory`-breakpoint`_`_ `$`{serial`_number`}`" as argument. 
In our example serial number is 925:&]
[s0; &]
[s0;= 
@@rawimage:3434&1555
([encoded data, 32748 characters])
&]
[s0; &]
[s3; Of course, the only problem with this is that the order of allocations 
must be exactly the same in the `"test run`". Which is often 
not, but usually it is possible to arrange it so after spending 
a couple of nights desperately looking for the source of leak 
in the code using other methods. So make sure that the serial 
number is still valid! In might be correct for several applications 
debug sessions, but in the end it will [* expire].&]
[s2;:3: 3. False positives&]
[s3; There is a very memory situation when memory leak can not be 
fixed by the programmer. For example the external library is 
used and there is not full control over it. Sometimes the operating 
system drivers leaks could be treated as leaks. To avoid such 
false positives U`+`+ library provides ignoring mechanisms.&]
[s3; The first one is the pair of function [* MemoryIgnoreLeaksBegin()] 
and [* MemoryIgnoreLeaksEnd()]. The below example show how to avoid 
leak detection:&]
[s0; &]
[s4; #include <Core/Core.h>&]
[s4; &]
[s4; using namespace Upp;&]
[s4; &]
[s4; CONSOLE`_APP`_MAIN&]
[s4; `{&]
[s4; -|MemoryIgnoreLeaksBegin();&]
[s4; -|int`* a `= new int(5);&]
[s4; -|MemoryIgnoreLeaksEnd();&]
[s4; `}&]
[s0; &]
[s3; The alternative simpler approach is to used [* MemoryIgnoreLeaksBlock] 
structure. On construction it starts ignoring and on destruction 
it cancels ignoring statement. This is the classical RAII pattern. 
Example below:&]
[s0; &]
[s0;l321; [C@5;1 #include <Core/Core.h>]&]
[s4; &]
[s4; using namespace Upp;&]
[s4; &]
[s4; CONSOLE`_APP`_MAIN&]
[s4; `{&]
[s4; -|`{&]
[s4; -|-|MemoryIgnoreLeaksBlock `_`_;&]
[s4; -|-|int`* a `= new int(5); [@(28.127.0) // <`- This leak will be 
ignored]&]
[s4; -|`}&]
[s4; -|int`* b `= new int(10); [@(28.127.0) // <`- This leak will be 
catched]&]
[s4; `}&]
[s0; &]
[s3; The memory leak detection mechanisms should be use with caution. 
In the vast majority of cases detections means that something 
is wrong in the application source code.&]
[s0; ]]