This very small program demonstrates a bug in handling FILEs of a particular RECORD. It has been cut down from a much larger real-life example, so it looks very artificial. File F (a FILE of TSMALLPOINT) is not written correctly using GPC version 20010516 (based on 2.95.2 19991024 (release)) on Kernel 2.2.16 on an i686 under RedHat Linux 6.2. The behaviour has changed sometime since version 19991030 (based on 2.95.2 19991024 (release)). Here is the program: ==================== program daj23(input,output); const MAXCOMP=5; MAXROUND=2; type TSMALLPOINT=RECORD REGNO:integer; PNTS:ARRAY[1..MAXROUND] OF integer; END; var i,J,cat,count,ordinal:INTEGER; st1:string(255); PROCEDURE SAVE_CAT; VAR I,J:INTEGER; F:FILE OF TSMALLPOINT; BEGIN writeSTR(st1,CAT:1); REWRITE(F,'ch'+ST1); F^.REGNO:=ORDINAL; for j:=1 to maxround do f^.pnts[j]:=0; PUT(F); FOR I:=1 TO MAXCOMP DO BEGIN F^.REGNO:=100+i; FOR J:=1 TO MAXROUND DO BEGIN F^.PNTS[J]:=i+j; END; PUT(F); END; CLOSE(F); END; begin (*daj20*) cat:=1; ordinal:=10; save_cat; end. (*daj20*) od -d ch1 shows the file contains: 0000000 0 0 0 0 0 0 0 0 0000020 0 0 3 0 0 0 0 0 0000040 4 0 0 0 0 0 5 0 0000060 0 0 0 0 6 0 0 0 0000100 0 0 7 0 0000110 Under GPC version 19991030, od -d ch1 shows: 0000000 10 0 0 0 0 0 101 0 0000020 2 0 3 0 102 0 3 0 0000040 4 0 103 0 4 0 5 0 0000060 104 0 5 0 6 0 105 0 0000100 6 0 7 0 0000110 which is the correct contents. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>
David James wrote:
This very small program demonstrates a bug in handling FILEs of a particular RECORD. It has been cut down from a much larger real-life example, so it looks very artificial.
Thanks for the report. Will be fixed soon. Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
In article <200106020110.DAA16603@goedel.fjf.gnu.de>, Frank Heckenbach <frank@g-n-u.de> writes
David James wrote:
This very small program demonstrates a bug in handling FILEs of a particular RECORD. It has been cut down from a much larger real-life example, so it looks very artificial.
Thanks for the report. Will be fixed soon.
Sorry to be a nuisance but I have now seen another different instance of what I suspect is this problem which is pretty crippling for us. My options are to go back to the earlier version of the compiler or wait for a fix. Any idea on a time scale for a fix i.e. how long is soon? -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.
Martin Liddle wrote:
Sorry to be a nuisance but I have now seen another different instance of what I suspect is this problem which is pretty crippling for us. My options are to go back to the earlier version of the compiler or wait for a fix. Any idea on a time scale for a fix i.e. how long is soon?
The fix should now be in the current CVS and source alphas. Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
In article <200106070100.DAA31405@goedel.fjf.gnu.de>, Frank Heckenbach <frank@g-n-u.de> writes
Martin Liddle wrote:
Sorry to be a nuisance but I have now seen another different instance of what I suspect is this problem which is pretty crippling for us. My options are to go back to the earlier version of the compiler or wait for a fix. Any idea on a time scale for a fix i.e. how long is soon?
The fix should now be in the current CVS and source alphas.
Thanks. I'll try it later today and report back. -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.
In article <e4V1ATAPhzH7Ew8s@tcs02.demon.co.uk>, Martin Liddle <martin@tcs02.demon.co.uk> writes
In article <200106070100.DAA31405@goedel.fjf.gnu.de>, Frank Heckenbach <frank@g-n-u.de> writes
Martin Liddle wrote:
Sorry to be a nuisance but I have now seen another different instance of what I suspect is this problem which is pretty crippling for us. My options are to go back to the earlier version of the compiler or wait for a fix. Any idea on a time scale for a fix i.e. how long is soon?
The fix should now be in the current CVS and source alphas.
Thanks. I'll try it later today and report back.
I've now downloaded 20010604 and preliminary testing suggests the problem is fixed. We'll do more rigorous testing over the next few days. Thanks you for the usual speedy response. -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.
In article <JMkwdXAI33H7Ew8p@tcs02.demon.co.uk>, Martin Liddle <martin@tcs02.demon.co.uk> writes
I've now downloaded 20010604 and preliminary testing suggests the problem is fixed. We'll do more rigorous testing over the next few days.
Just to close this thread off, I can now report that we have done extensive testing and have seen no further problems with file writing. We are also confident that the memory leak problem has been fixed. Hooray. -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.
participants (3)
-
david＠tcs01.demon.co.uk -
Frank Heckenbach -
Martin Liddle