-gc, is apparently only useful in very limited scenarios, such as applications, that have no interaction with the OS at all, or can otherwise gurantee, never to access any memory that was returned by (and therefore allocated by) the OS.

An LCL app can not guarantee that...

Yet what I am looking for is a simpler variant, that can help doing the same for class-instances, or dyn-array.

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.

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). Therefore I would guess (just guess...) that such a check could be done?
It would greatly help finding any access to freed data.

Any comments, any chance for something like that? Or am I overlooking it, and it already exists?

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

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

No, it only means allocation should be done in a dedicated memory manager that registers classes and dynarrays (or any) for GC. I already did that with my Boehm implementation (based on another one by Barry Kelly that also did do just that and I borrowed most of the idea's from) but for some reason people on this forum think this is too slow. It isn't.
(RTM, P!)
I have it running in many a production scenario for at least 4 years (big ones)
My Boehm GC version is actively maintained, so try that one.

See above.

Yes, easy.

It would greatly help finding any access to freed data.

The Boehm GC has options (the registered memory is maintained and accessible) for that during debugging, but not for production quality. That would defeat the point of a GC.