FreePascal V 2.2.2 problems
David Mitchell
This is intended for the developers of the above, as their web-site is
impossibly slow to use - I can't even get the home page up - and I know
they look in on this newsgroup now and again.
I'm having real problems with what I'm fairly sure is a compiler bug, and
I'd love to know how I can get some help (without, obviously, using the
web-site).
I can provide loads of information, including sources; but the gist of it
is, code which has been working fine has stopped; but, and here's the
good bit, putting a WriteLn in above a particular method call makes it
work!
To illustrate:
function tType_dec.CompiledOK(var decModifier : tDecModifier):boolean;
var ok : boolean;
i : longword;
typeIndex : tItemIndex;
namePtr : longword;
newName : tItemIndex;
typePtr : tTypeDefPtr;
begin
fault.line:=line;
{WriteLn;}
i:=0;
ok:=type_def^.CompiledOK(typeIndex);
if not ok then Write('Not ');
WriteLn('ok is ',integer(ok));
if ok then begin
etc.
If I leave the WriteLn commented out, the value of 'ok' is 0.
If I include the writeLn, the value of 'ok' is 104 (which, given that
it's boolean, is a little surprising).
Any help would be gratefully received, as this is a show-stopper for me.
--
=======================================================================
= David --- If you use Microsoft products, you will, inevitably, get
= Mitchell --- viruses, so please don't add me to your address book.
=======================================================================
David Mitchell
David Mitchell
> Hi,
Hi again,
Sorry for the duplicate post, and, also, the e-mail address on the
previous posts is wrong: the one on this post is correct.
Marco van de Voort
> I can provide loads of information, including sources;
Start narrowing it down to a minimal amount of code (preferable <100lines).
Chances that you find it yourself. Otherwise file a bug.
> but the gist of it
> is, code which has been working fine has stopped; but, and here's the
> good bit, putting a WriteLn in above a particular method call makes it
> work!
That is suspect, but it can be simply a bug in the programg that corrupts
the stack suddenly becoming less critical due to a change in stack layout
caused by writeln allocating a tempstring, which is mostly idle space.
Isolating it by cutting more and more code can sometimes make you find these
kinds of bugs.
David Mitchell
> On 2009-03-26, David Mitchell <da...@edenroad.demon.clo.uk> wrote:
>> I can provide loads of information, including sources;
>
> Start narrowing it down to a minimal amount of code (preferable
> <100lines).
Tricky, although a lot of it is auto-generated (and probably, therefore,
correct).
> Chances that you find it yourself.
I hope so.
> Otherwise file a bug.
I'd love to; but as I suggested earlier, your web-site is almost
impossible to use. The main page just doesn't ever come up, and the
"Bug" menu selection on the Wiki page times out halfway though, every
time I try.
>
>> but the gist of it
>> is, code which has been working fine has stopped; but, and here's the
>> good bit, putting a WriteLn in above a particular method call makes it
>> work!
>
> That is suspect, but it can be simply a bug in the programg that
> corrupts the stack suddenly becoming less critical due to a change in
> stack layout caused by writeln allocating a tempstring, which is mostly
> idle space.
Something funny is certainly going on, there are now two places at which
simply putting a blank WriteLn will make it work.
Marco van de Voort
>>> I can provide loads of information, including sources;
>>
>> Start narrowing it down to a minimal amount of code (preferable
>> <100lines).
>
> Tricky, although a lot of it is auto-generated (and probably, therefore,
> correct).
So is the compiler output :-)
>> Chances that you find it yourself.
>
> I hope so.
>> Otherwise file a bug.
>
> I'd love to; but as I suggested earlier, your web-site is almost
> impossible to use. The main page just doesn't ever come up, and the
> "Bug" menu selection on the Wiki page times out halfway though, every
> time I try.
Yes. Sometimes ISPs don't like eachother, and iirc the one of FPC's site has
problems with some others that have non standard MTU or packet fragmentation
needs. (from an older msg:)
(it's (probably) a configuration problem having to do with packet
fragmentation, and dropping ICMP needs-fragmentation replies, but I'm
unsure)
The site is sponsored, so there is not much we can do, and afaik it affects
only a very small number of people. I can only advise to see if using a
free proxy, or work via a VPN works.
In a total emergency, you can mail it to me, and I'll add it. Be sure to remind
me here, so I check spam boxes for it.
>> That is suspect, but it can be simply a bug in the programg that
>> corrupts the stack suddenly becoming less critical due to a change in
>> stack layout caused by writeln allocating a tempstring, which is mostly
>> idle space.
>
> Something funny is certainly going on, there are now two places at which
> simply putting a blank WriteLn will make it work.
It can be both. IOW pointer mistakes in your own code, and a compiler bug
can never be excluded (though rare).
What I usually do is to reduce the offending procedure in size as much as
possible, and then inspect the generated assembler in both cases (using
-al), and see if I can easily see if something is wrong, a value in a
register that is calculated but not used, a register that is used without
being written.
Best is to try with multiple FPC and Delphi versions and with as many settings
as possible. (play with options like optimization,stackframes, runtime error
checking) to force bugs to expose themselves. I haven't experimented with it
yet, but it is said that -gt, which initializes local variables to trash is
very powerful in this regard)
But anyway, to make it doable, a large body of code needs to be
reduced,reduced,reduced.
David Mitchell
> On 2009-03-27, David Mitchell <david.robo...@googlemail.com>
> wrote:
> In a total emergency, you can mail it to me, and I'll add it. Be sure to
> remind me here, so I check spam boxes for it.
Thank you, I'll try to find it myself first, so I don't waste anyone's
time.
> It can be both. IOW pointer mistakes in your own code, and a compiler
> bug can never be excluded (though rare).
I have had some funny experiences with this version of the compiler: a
procedure which worked until I made the first parameter a "const", at
which point the parameter value was passed incorrectly; I have also had
set constants which sometimes failed to compile, or to work correctly
when they did - and that was certainly a compiler bug; but it didn't
always happen - the code is compiling correctly at the moment, for
example, even though it hasn't changed.
>
> What I usually do is to reduce the offending procedure in size as much
> as possible, and then inspect the generated assembler in both cases
> (using -al), and see if I can easily see if something is wrong, a value
> in a register that is calculated but not used, a register that is used
> without being written.
The assembler is almost identical in both cases - only the labels seem to
be different.
>
> Best is to try with multiple FPC and Delphi versions and with as many
> settings as possible. (play with options like optimization,stackframes,
> runtime error checking) to force bugs to expose themselves.
I've tried a couple of optimisation settings - currently set to none; but
it makes no difference.
> I haven't
> experimented with it yet, but it is said that -gt, which initializes
> local variables to trash is very powerful in this regard)
Thanks, I'll give it a try.
David Mitchell
> On Sat, 28 Mar 2009 12:33:08 +0000, Marco van de Voort wrote:
>> I haven't
>> experimented with it yet, but it is said that -gt, which initializes
>> local variables to trash is very powerful in this regard)
>
> Thanks, I'll give it a try.
Seems to make it work!
Ie. it works with -gt, and doesn't without.