[fpc-devel] limited -gc ?

[Martin]

On 09/10/2011 21:44, Jonas Maebe wrote:
> On 09 Oct 2011, at 22:34, Martin wrote:
>
>> 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)
Ok, but that is can still be done via the fpc mem manager? Yes it can 
bypass it, so yes like -gc you can write apps where the check will give 
false positives.

But it would probably happen less than with -gc

>> 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.
I can't judge that, If you say so, then that's that.  :(


> 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.
Ups yes, true.

> 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).
I haven't got any suspected code right now.

But I always like the idea to run all code while developing it, with the 
maximum checks I can.

running code with -Crti -gh etc is all fine and can be done for every run.

Dr Memory is something I would do, every now and then. But code that is 
believed to be free of such problem, but that unexpectedly might have 
the problem,  would probably not expose it on every run. It might just 
happen once a month or less. So only a solution that checks 100% every 
run, will help catching such unknown and unexpected issues.

> 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.
>
Thanks for the answer anyway