[fpc-devel] Const optimization is a serious bug

[Alexander Klenin]

On Wed, Jul 6, 2011 at 02:41, Martin <fpc at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: heaptrc_poisoning.patch
Type: application/octet-stream
Size: 373 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110706/b6977866/attachment.obj>