On Wed, Jul 6, 2011 at 02:41, Martin <f...@mfriebe.de> wrote: > On 05/07/2011 16:28, Florian Klaempfl wrote: >> >> As written in some of the bug reports, I consider as a better solution: >> - Pointer checking of constant parameters of types like ansistrings, >> interfaces at procedure exit. Together with heaptrc and keep_released >> enabled, this catches all cases of disposed const parameters and >> probably a lot more pointer errors. >> - Like the scrambling of local parameters with -gttt, some checksumming >> for contant parameters could be implemented. This catches not only the >> modified constant parameter but also aliasing problems. > > There would be the possibility to extend heaptrc mem manager. > Every mem block gets a "release-lock"- or const-counter (and maybe a > checksum field). > > then any memory used in a const param, can be protected (via the mem > manager) against release (ONLY if compiled with sanity check). > > That would catch the releases due to refcount going to 0, were it must not > be allowed. > > The checksum can be used for general checking. > > The checksum should be toggle-able by a 2nd switch (and maybe with a > configurable upper limit for mem size, so to skip tests for very large data) >
This seems complicated to me. How about a simple memory poisoning? For example, with the attached patch the code trying to access const string parameter which has been already destroyed is likely to fail spectacularly instead of "maybe working" depending on memory layout. -- Alexander S. Klenin
heaptrc_poisoning.patch
Description: Binary data
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
