How do I interpret C++Builder CodeGuard Output?

Question

CodeGuard has made this announcement:

9/12/2022 7:04:08 PM started a CodeGuard(tm) process: MyProg.exe(12200)  
Resource leak in process: MyProg.exe(12200)  - System.pas#4942  
  The memory block (0x305EBC0) was never freed  
  The memory block (0x0305EBC0) [size: 16 bytes] was allocated with SysGetMem  
    0x00F6BAAE - System.pas#4942  
    0x0128535B  
    0x012853A7  
    0x0128552A  

I don't know what System.pas is. How do I identify "The memory block (0x305EBC0)"? Where do I look to find where the array was allocated?

Answer 1

system.pas is part of VCL. You know VCL is written in PASCAL that is why *.pas files are still compilable in C++ Builders... This hints the problem is with some VCL component usage ...

The error showed that on your App exit or some class destructor some VCL stuff was never freed/released this might be forgotten delete or delete[] on your part however I have seen these also as a result of compiler error on C++Bulder part too.

If you are on older C++Builder version like me see related:

• bds 2006 C hidden memory manager conflicts (class new / delete[] vs. AnsiString)

Problems like these often emerge (in my experience) if you:

1. create/allocate VCL components (especially forms) on your own using new,delete.

2. have global AnsiString constants with unaligned length (not multiple of 4 bytes)

   In my opinion this is not really a bug of AnsiString but the CodeGuard itself I witnessed many times that even accessing runtime variable AnsiStrings produced such error in some cases but without CodeGuard all runs fine...

3. have name conflicts with VCL or any other lib included

   this is very common if you use english names for your stuff too... VCL usually start with Upper case letter like Draw sometimes if you declare your own Draw those two can be mixed without compiler error producing error. Such project tend on some builds use correct and on other the wrong Draw (for example after any minor change in source like adding empty line or space).

4. have used inbuild units instead of normal *.h,*.cpp file #include they are compiled differently

   Have seen this many times especially in BCB6 such project sometimes are wrongly compiled without any errors but the code does not do what should...

   So do not Add to Project files that should be just normaly #included most of the time stuff works as expected however once the project grows bigger such exchange tend to produce problems ...

However if this bug is present only on App exit then its no a big deal as OS will free the stuff anyway so no real memory leak occurs. Getting rid of these is not easy (and sometimes even not possible)

To identify the memory block You could check your visual components in Watch window if you add there for Example Form1 you will see the pointer value in hexa. However if you have too many components checking all of them will be nuisance...

To identify the location where the error was produced you have to inspect your call trace what happpened before 0x00F6BAAE - System.pas#4942 so click on the other addresses bellow it it should show one call back ... until you hit your own code