[fpc-devel] limited -gc ?

[Jonas Maebe]

On 09 Oct 2011, at 22:34, Martin wrote:

> For classes there is -CR but it act only when calling methods (any method or only virtual methods?), I can for example not tell if accessing a property mapped to field would also trigger tests on this.

It also checks every typecast. Accessing fields or properties is not checked.

> Every class or dyn array should be in a block of memory allocated by the fpc heap mgr (probably even always at the start (or fixed offset) of such a block).

That is incorrect: classes can override newinstance and allocate memory in whichever way they want (e.g. for memory pooling purposes)

> Therefore I would guess (just guess...) that such a check could be done?
> It would greatly help finding any access to freed data.

It is possible, but I believe the added complexity in the compiler is not worth it. If you have memory problems related to accessing freed blocks, use Valgrind (Mac OS X, Linux) or Dr Memory (Windows, Linux), and they will detect both those errors and many more which the compiler will never be able to help you with.

And at least with dynamic arrays it is not possible to access freed memory unless you have some other memory corruption bug in your program that overwrites random data, since their memory allocation is managed by the compiler. In that case you need help finding the code that overwrites the random data, which again is the domain for Valgrind/Dr Memory (or a debugger with a watchpoint in case the corruption does not happen via either a pointer into a previously freed block or via a pointer containing an uninitialized value).

The compiler contains some lightweight things for higher-level checking (such as the type-based checks by -CR). Lower level issues, such memory corruption, use after free, etc are the domain of dynamic instrumentation tools.


Jonas